==============================================================
Guild: wafer.space Community
Channel: 📐 - Designing / 📝-project-template
Topic: [template-github](https://github.com/wafer-space/gf180mcu-project-template)
After: 2025-10-31 11:59 p.m.
Before: 2025-12-01 12:00 a.m.
==============================================================

[2025-11-01 7:17 p.m.] tholin
Getting some *extreme* hold violations when integrating a macro into chip_top that is not present when hardening the macro itself. Checking the logs, the worst slack is simply from the reset pad.

{Attachments}
2025-11_media/image-91CC9.png


[2025-11-01 7:21 p.m.] markemer
Is that in ns? If so, oof. And could it be a bad capacitance extraction on the pads themselves?


[2025-11-01 7:28 p.m.] 246tnt
That's probably because the macro has its own clock tree. So the clock that its internal FF sees is delayed by many ns compared to the clock on its input pin.


[2025-11-01 7:29 p.m.] 246tnt
If the CTS inside your top level project isn't setup to feed the macro an "early clock" (i.e. from the root of its clock tree instead of a leaf), that could explain why you see so many hold violations.


[2025-11-01 7:30 p.m.] 246tnt
(Just a theory of course ... can't do more than theorize without more data)


[2025-11-01 7:45 p.m.] tholin


{Attachments}
2025-11_media/image-226EA.png


[2025-11-01 7:45 p.m.] tholin
I don't have a repo for this yet


[2025-11-01 7:46 p.m.] tholin
There is no CTS in the top level


[2025-11-01 7:46 p.m.] tholin
Actually, there is no standard cells in the top level


[2025-11-01 7:46 p.m.] tholin
Just macros


[2025-11-01 8:56 p.m.] tholin
I guess this calls for a custom SDC file. I started by copying the SDC file provided by efabless for user project macros and will progressively modify it.


[2025-11-01 10:33 p.m.] tholin
Literally nothing I do is changing the hold violations. Its refusing to budge.


[2025-11-02 4:16 p.m.] tholin
Almost got it. Commit soon. Just trying to clean up my SDC file.


[2025-11-02 4:17 p.m.] tholin
What’s the point of `set_driving_cell`? Does it automatically determine slew rates and delays, or do I still need to specify those manually?


[2025-11-02 4:42 p.m.] tholin
Doesn’t matter. I cannot `set_driving_cell -lib_cell gf180mcu_fd_io__bi_24t` inside my macro SDC files anyways:

{Attachments}
2025-11_media/image-55734.png


[2025-11-02 6:10 p.m.] mole99
Do you use the LibreLane version from the template or [this branch](https://github.com/librelane/librelane/pull/806)?
Otherwise the pad cells are not read in.


[2025-11-02 6:16 p.m.] tholin
I cannot use the LibreLane version from the template for my macros. Python error.

{Attachments}
2025-11_media/image-BC7E4.png


[2025-11-02 6:17 p.m.] tholin
I mean, the PDK Version


[2025-11-02 6:18 p.m.] tholin
The error during GPL I reported before persists, so I cannot use the LibreLane version.


[2025-11-02 6:21 p.m.] tholin
But I also don’t understand what `set_driving_cell` even does. Right now my approach has been to determine values to set on `set_input_delay` , `set_clock_latency`, `set_input_transition` and `set_clock_transition` by manually interpreting the values in the liberty files for the IO pads.


[2025-11-02 6:21 p.m.] tholin
Except when it comes to the internal bus inside the chip, where I have to rely on STA for numbers.


[2025-11-02 6:23 p.m.] tholin
Actually, it seems fine now, at least on this one macro, but there is still a big difference in behavior.


[2025-11-02 6:24 p.m.] tholin
I just got to `Stage 37 - Resizer Timing Optimizations (Post-Clock Tree Synthesis)` on this CPU macro and on Iteration 0 its starting with a TNS of **-5042** compared to main librelane, where I got -250.


[2025-11-02 6:24 p.m.] tholin
I changed nothing about the config.


[2025-11-02 6:24 p.m.] tholin
Just switched LL versions.


[2025-11-02 7:22 p.m.] tholin
Yeah, I’m getting severe performance degradation in the wafer.space template LL version in two ways. The timings of the design are worse, and also the flows take forever to run. After one hour, it is still stuck in Timing Optimizations. This whole flow used to take < 15 minutes. @Leo Moser (mole99)


[2025-11-03 12:24 a.m.] tholin
@Leo Moser (mole99) This page linked in the README of the template no longer exists.

{Attachments}
2025-11_media/image-C502E.png


[2025-11-03 12:24 a.m.] tholin


{Attachments}
2025-11_media/image-6E9A7.png


[2025-11-03 7:16 a.m.] mole99
The wafer.space gf180mcu PDK requires the LibreLane version in the template (or from the branch).


[2025-11-03 7:17 a.m.] mole99
The issue is still open at OpenROAD's side: https://github.com/The-OpenROAD-Project/OpenROAD/issues/8229
However, as mentioned before, you can simply disable timing driven placement.


[2025-11-03 7:18 a.m.] mole99
`set_driving_cell` automates exactly that. It takes the values directly from the LIB.


[2025-11-03 7:19 a.m.] mole99
Thanks for reminding me. The LibreLane docs have recently been updated.


[2025-11-03 8:12 a.m.] tholin
Thank you. I could find 0 information about this command online.


[2025-11-03 8:23 a.m.] 246tnt
https://github.com/The-OpenROAD-Project/OpenSTA/blob/master/doc/OpenSTA.pdf

{Embed}
https://github.com/The-OpenROAD-Project/OpenSTA/blob/master/doc/OpenSTA.pdf
OpenSTA/doc/OpenSTA.pdf at master · The-OpenROAD-Project/OpenSTA
OpenSTA engine. Contribute to The-OpenROAD-Project/OpenSTA development by creating an account on GitHub.
2025-11_media/OpenSTA-8A0D3


[2025-11-03 8:35 p.m.] mole99
This is the ✨ magic ✨ line for the `gf180mcu_fd_ip_sram__sram512x8m8wm1` SRAM:

```
add_pdn_stripe -grid macro -layer Metal4 -width 2.36 -offset 1.18 -spacing 0.28 -pitch 426.86 -starts_with GROUND -number_of_straps 2
```

It adds a power/ground pair on each side of the SRAM macro, directly above the pins. Since this uses the local coordinate system of the macro, you can move the macro around as you wish, the PDN straps will follow. As the PDN straps go all the way across the macro, connecting them to the PDN above is very easy.

{Reactions}
✨ 💯

[2025-11-03 8:35 p.m.] mole99
(top left)

{Attachments}
2025-11_media/Bildschirmfoto_vom_2025-11-03_21-13-08-89A4F.png


[2025-11-03 8:35 p.m.] mole99
(top right)

{Attachments}
2025-11_media/Bildschirmfoto_vom_2025-11-03_21-13-33-4F47A.png


[2025-11-03 8:35 p.m.] mole99
If you rotate the SRAM by 90 or 270 degrees, you need to use this line:

```
add_pdn_stripe -grid sram_macros_WE -layer Metal4 -width 2.36 -offset 1.18 -spacing 0.28 -pitch 479.88 -starts_with GROUND -number_of_straps 2
```

Unfortunately, the connection to VSS is not as good on the right side. It is better to use the first orientation.

Don't forget the PDN connect:

```
add_pdn_connect \
    -grid macro \
    -layers "$::env(PDN_VERTICAL_LAYER) Metal3"
```


[2025-11-03 8:35 p.m.] mole99


{Attachments}
2025-11_media/Bildschirmfoto_vom_2025-11-03_21-30-41-0737D.png


[2025-11-03 8:35 p.m.] mole99
Now I just need to make magic DRC happy, and then I can push the the example usage of the SRAM to the template repo.


[2025-11-03 8:36 p.m.] tholin
Awesome


[2025-11-03 8:36 p.m.] tholin
I re-used my setup from GFMPW with a wrapper macro for the SRAM that just added the Metal4 strips.


[2025-11-03 8:36 p.m.] tholin
Which is not optimal


[2025-11-03 8:37 p.m.] mole99
Well, if I remember correctly, Efabless used your solution too :)


[2025-11-03 8:37 p.m.] tholin
Yeah. That’s where I got it from.

{Reactions}
👍

[2025-11-03 8:45 p.m.] mole99
Started a thread.


[2025-11-05 5:53 a.m.] greg.hashtag.9468
I've setup a new system following the readme. And then just run the stock template as a sanity check, it does complete. But I'm seeing KLayout DRC errors. (along with timing/cap/slew warnings at some corners)
```
...
    "DM4.8": 0,
    "DF.12": 3,
    "NW.2b_MV": 16,
    "DPF.4": 38,
    "DCF.4": 48,
    "total": 105
}
```
Is this expected? Or does it indicate something I should debug with my environment first?


[2025-11-05 7:38 a.m.] mole99
Started a thread.


[2025-11-06 10:32 a.m.] mole99 (pinned)
📢 It's update time!

The project template has been updated with support for the foundry SRAMs!
Two SRAMs of type `sram512x8m8wm1` are instantiated in `chip_core` and placed inside the chip in two different orientations (north and east).
If you add more SRAMs, make sure to update the LibreLane config (`librelane/config.yaml`) and the PDN configuration (`librelane/pdn_cfg.tcl`).

In addition, an issue has been fixed with filler generation, the way how the KLayout DRC deck was invoked (connectivity rules), and an error in the seal ring generator. With these changes the template is now DRC clean for both the magic and KLayout DRC deck.
Furthermore, the design is LVS clean and the there are no setup and hold violations for this example.

Please update your projects to the latest template, and don't forget to update the PDK as well (`make clone-pdk`).
Let me know if you have any questions.

{Reactions}
waferspace (5) 👍 (2) 🎉

[2025-11-06 10:46 p.m.] tholin
Updated my AS2650v2 wafer.space port to use the new method for instantiating SRAMs.

{Reactions}
💜

[2025-11-06 10:46 p.m.] tholin
Works!


[2025-11-07 5:46 a.m.] mole99
Great to hear 👏🏻


[2025-11-07 12:03 p.m.] mithro_
Pinned a message.


[2025-11-07 12:04 p.m.] mithro_
@Leo Moser (mole99) - Has performance / RAM usage changed much in the latest updates?


[2025-11-07 12:26 p.m.] mole99
RAM usage has gone down drastically during the filler generation step after I fixed a bug there. However, that was already before this update.


[2025-11-17 10:35 a.m.] 246tnt
How long does the template build (default) take for people ?


[2025-11-17 10:35 a.m.] 246tnt
Just wondering if my vm is slow or something ...


[2025-11-17 10:39 a.m.] mole99
The CI takes around 50mins without DRC: https://github.com/wafer-space/gf180mcu-project-template/actions/runs/19297076321/job/55181634117
Locally, it's faster for me. The DRC can then take an additional 1–1.5 hours.

{Reactions}
👍

[2025-11-17 1:35 p.m.] 246tnt
Here full run took 3h30 😅 
Looking at timestamps, klayout drc was 2h 48 min of that.


[2025-11-17 1:36 p.m.] tholin
What? My top-level DRC runs don't take nearly as long.


[2025-11-17 1:37 p.m.] tholin
I'm also still struggling with analog pads not getting wired up.


[2025-11-17 2:18 p.m.] mole99
Just had a full run (inlcuding DRC) in 48:05 using the template 😁


[2025-11-17 2:21 p.m.] 246tnt
Huh ... that's worrying ...


[2025-11-17 5:57 p.m.] tholin
Something changed. KLayout DRC is so much slower now.


[2025-11-17 6:52 p.m.] mole99
There haven't been changes to the PDK for two weeks: https://github.com/wafer-space/gf180mcu
Although a number of changes are coming up.

{Embed}
https://github.com/wafer-space/gf180mcu
GitHub - wafer-space/gf180mcu: Temporary development repository for...
Temporary development repository for the gf180mcuD PDK variant. - wafer-space/gf180mcu
2025-11_media/gf180mcu-6FE46


[2025-11-17 9:17 p.m.] tholin
And why are my analog signals not getting routed?

{Attachments}
2025-11_media/image-C20A2.png

{Reactions}
😮

[2025-11-17 9:31 p.m.] tholin
I CTRL+F’d for "analog" in the global routing logs and found nothing. Its skipping it.


[2025-11-17 9:33 p.m.] 246tnt
Are they defined any differently in your netlist ?


[2025-11-17 9:35 p.m.] tholin
No


[2025-11-18 11:26 a.m.] rzioma
Z80 design is finally green on github \o/
@Leo Moser (mole99) is there a way to download artifacts / GDS from github job for local inspection? *I feel quite dumb for asking, but I couldn't figure how to do it so far*

{Attachments}
2025-11_media/image-95F6F.png

{Reactions}
🎉

[2025-11-18 11:30 a.m.] rzioma
Ah, when building locally on Mac it is necessary to increase file-descriptor count otherwise Magic streamout fails `ulimit -n 1024`


[2025-11-18 11:32 a.m.] rzioma
@Leo Moser (mole99) I tried to add `ulimit` to flake.nix as shell hook, but failing so far even with ChatGPT *"help"* 😓


[2025-11-18 11:43 a.m.] mole99
Hi ReJ! Congrats 👏
Just so you know, the CI only runs the implementation, as the DRC requires too much memory. So you need to make sure to run DRC locally.

Yes, there are ways to upload artifacts: https://docs.github.com/en/actions/tutorials/store-and-share-data
I haven't added this to the CI yet since I though it would quicky fill up the available storage space. But perhaps with a compression of the artifacts and a short retention time, it could be fine?

{Reactions}
❤️

[2025-11-18 11:45 a.m.] rzioma
For some reason I get hold violations when I build locally (MacOS could be a problem here 😉 ), but it is fine building on github. Investigating atm.


[2025-11-18 11:59 a.m.] mole99
The Nix flake in the template uses LibreLane's create-shell: https://github.com/librelane/librelane/blob/dev/nix/create-shell.nix
It seems that mkShell has a `shellHook` that could be used for that. However, I'm not sure how to override this from the template.

{Reactions}
👍

[2025-11-18 12:02 p.m.] mole99
Strange. There may be slight differences between the Linux and mac version of OpenROAD. If your hold violations are only just over the limit, perhaps that could make the difference.
Make sure your clock tree is good, and you could increase the `PL_RESIZER_HOLD_SLACK_MARGIN`.


[2025-11-18 12:21 p.m.] tholin
All of my configs contain
```
GRT_RESIZER_HOLD_SLACK_MARGIN: 0.1
PL_RESIZER_HOLD_SLACK_MARGIN: 0.1
PL_RESIZER_HOLD_MAX_BUFFER_PCT: 100
```
by default now since I had hold violations screw me over before.

{Reactions}
👍

[2025-11-18 12:45 p.m.] bailey8889
@ReJ aka Renaldas Zioma If you're just running a batch job with no editing, you probably don't need file locking. Disabling this with the magic command `locking disable` may allow you to load large designs without changing the ulimit. http://opencircuitdesign.com/magic/commandref/locking.html

{Reactions}
👍

[2025-11-18 3:43 p.m.] _luke_w_
Is it expected to get some antenna violations from building the project template?
```
* Antenna
Failed 𐄂
Pin violations: 17
Net violations: 11
Check the report directory of OpenROAD.CheckAntennas.
```

checking the CI run here I do see the same violations: https://github.com/wafer-space/gf180mcu-project-template/actions/runs/19297076321/job/55181634117

{Embed}
https://github.com/wafer-space/gf180mcu-project-template/actions/runs/19297076321/job/55181634117
Remove `set_driving_cell` from SDC file · wafer-space/gf180mcu-pro...
Project template for wafer.space MPW runs using the gf180mcu PDK - Remove `set_driving_cell` from SDC file · wafer-space/gf180mcu-project-template@9b6c284
2025-11_media/gf180mcu-project-template-DF039


[2025-11-18 3:47 p.m.] 246tnt
Yes


[2025-11-18 3:47 p.m.] _luke_w_
Ok, thanks 🙂 are they concerning or just something to waive?


[2025-11-18 4:08 p.m.] mole99
That is something that requires a closer look into OpenROAD and LibreLane in order to find a proper solution. For large ratios you can manually insert ECO diodes.

So far, most (all?) Tiny Tapeout designs seem to work just fine, and almost all of them have some antenna violations.

{Reactions}
❤️

[2025-11-18 4:09 p.m.] mole99
Search for `INSERT_ECO_DIODES` in https://librelane.readthedocs.io/en/latest/reference/step_config_vars.html


[2025-11-18 5:25 p.m.] _luke_w_
Thanks, I guess I'll worry about that later then 😅

{Reactions}
😁

[2025-11-18 5:25 p.m.] _luke_w_
In `chip_core.sv` in the example project, why does it have `keep` attributes on the SRAM? Are they just left in from initial hacking or are they required?

```
    logic [7:0] sram_0_out;

    (* keep *)
    gf180mcu_fd_ip_sram__sram512x8m8wm1 sram_0 (
        `ifdef USE_POWER_PINS
        .VDD  (VDD),
        .VSS  (VSS),
        `endif

        .CLK  (clk),
        .CEN  (1'b1),
        .GWEN (1'b0),
        .WEN  (8'b0),
        .A    ('0),
        .D    ('0),
        .Q    (sram_0_out)
    );
```


[2025-11-18 5:26 p.m.] _luke_w_
I will happily cargo cult it into my own memory wrappers, I was just curious


[2025-11-18 5:28 p.m.] mole99
The former. You should be able to remove the `(* keep *)` and since Yosys sees that the outputs of the macro are being used, it will keep it. I'll remove it the next time I push another change to the template :)


[2025-11-18 5:29 p.m.] _luke_w_
ok nice thanks, I thought that would be the case but wasn't sure if there were hidden gotchas

{Reactions}
👍

[2025-11-18 5:30 p.m.] _luke_w_
flow related question (if the answer is "RTFM" I can attempt to do that): in our ASIC flow at work, if I hand-instantiate a cell then the buffer width can be changed during layout but otherwise it'll remain the same cell with the same hierarchical path. Is that the case here or do I need to add `(* dont_touch keep *)` etc to my cell wrappers?


[2025-11-18 5:34 p.m.] mole99
Cell attributes are currently not retained. You can set `SYNTH_WRITE_NOATTR` to false and they should be passed on to OpenROAD.
However, there's `RSZ_DONT_TOUCH_RX` and `RSZ_DONT_TOUCH_LIST` if you want to keep a cell or net untouched.
I think if you just set the `(* keep *)` attribute on a stdcell, Yosys will instantiate the stdcell and OpenROAD is free to change it's buffer width.

{Reactions}
👍

[2025-11-18 5:34 p.m.] _luke_w_
nice, thanks


[2025-11-18 5:35 p.m.] _luke_w_
so it sounds like just putting `(* keep *)` on my cells is what I want; quite happy for the tools to change the drive as I don't fancy going and fixing all the transition violations myself 🙂

{Reactions}
👌

[2025-11-18 5:44 p.m.] h.tamas
FYI time driven placement (enabled by default) ignores the `RSZ_DONT_TOUCH_*` setting and resizes the cells nonetheless. You can work around it by setting `PL_TIME_DRIVEN` to 0.


[2025-11-18 5:47 p.m.] mole99
Yes, that is actually a "bug" in LibreLane as `dont_touch` does not prevent placement. So we could actually keep the attribute throughout GPL. See here: https://github.com/librelane/librelane/issues/695

{Reactions}
👍

[2025-11-18 8:32 p.m.] _luke_w_
Some incredibly minor DRCs (SRAM VDD/VSS *completely unconnected* while I figure out how the hierarchical paths are escaped) but in theory here is a processor, JTAG and 4 kB of RAM. Thanks for making the template, it made it super fast to get started 😄

{Attachments}
2025-11_media/image-DCA97.png

{Reactions}
❤️ (3) 🎉 (2)

[2025-11-18 8:35 p.m.] _luke_w_
Also I may have mixed up the SRAM dimensions and there is only a 15 um routing channel between the two rows 🤔


[2025-11-18 10:57 p.m.] _luke_w_
I'm guessing it's expected that the `librelane-magicdrc` makefile target crashes out during klayout/magic XOR, since klayout was skipped?


[2025-11-18 10:59 p.m.] _luke_w_
i.e.

```
Reading /home/luke/proj/riscboy-180/librelane/runs/RUN_2025-11-18_22-06-42/56-magic-streamout/chip_top.magic.gds ..
ERROR: In /nix/store/g3fml7j9yabcq2cmqm5yh19fxrm1h919-python3-3.12.10-env/lib/python3.12/site-packages/librelane/scripts/klayout/xor.drc: 'source': Stream has unknown format: /home/luke/proj/riscboy-180/librelane/runs/RUN_2025-11-18_22-06-42/56-magic-streamout/chip_top.magic.gds in Layout::read
Total elapsed: 0.010s  Memory: 413.00M
ERROR: RuntimeError: 'source': Stream has unknown format: /home/luke/proj/riscboy-180/librelane/runs/RUN_2025-11-18_22-06-42/56-magic-streamout/chip_top.magic.gds in Layout::read in Executable::execute
  /nix/store/g3fml7j9yabcq2cmqm5yh19fxrm1h919-python3-3.12.10-env/lib/python3.12/site-packages/librelane/scripts/klayout/xor.drc:78:in `execute'
  :/built-in-macros/drc_interpreters.lym:31:in `instance_eval'
  :/built-in-macros/drc_interpreters.lym:31:in `execute'
/home/luke/proj/riscboy-180/librelane/runs/RUN_2025-11-18_22-06-42/56-magic-streamout/chip_top.magic.gds
/home/luke/proj/riscboy-180/librelane/runs/RUN_2025-11-18_22-06-42/57-klayout-streamout/chip_top.klayout.gds
```

if it's a known issue with that target then I won't bother debugging 🙂


[2025-11-18 11:05 p.m.] _luke_w_
Does this YAML config go anywhere other than `chip_top.sdc`?

```
# Clock
CLOCK_PORT: clk_PAD
CLOCK_NET: clk_pad/Y

CLOCK_PERIOD: 40 # 25 MHz
```

I saw the warning about multiple clocks in there but hoping I can just ignore that and write a normal `.sdc` file.


[2025-11-19 7:20 a.m.] mole99
Started a thread.


[2025-11-19 7:22 a.m.] mole99
From what I know, this is only passed on to the SDC file.
Yes, you should be able to fully customize your SDC.

{Reactions}
👍

[2025-11-19 7:50 a.m.] rzioma
DRC is passing (minus some antenna violations).
Tiny Z80 looks so lonely in there.

{Attachments}
2025-11_media/Pasted_Graphic_12-0D70E.png

{Reactions}
blobclap (4)

[2025-11-19 7:55 a.m.] rzioma
@Leo Moser (mole99)  However I ran into some problems with `gf180mcu-precheck` repository. It:
- crashes on my Ubuntu machine (*perhaps running out of memory, investigating*) during the Density check
- fails to find qrcode library on OSX machine (*Error: Couldn't load the qrcode library.  *)


[2025-11-19 7:58 a.m.] mole99
Congrats! 👏
You did enable the environment within the precheck, right?
Because I specifically request the `qrcode` Python module 😅
https://github.com/wafer-space/gf180mcu-precheck/blob/1b639dff3d87a50e0759541701c7d162e1765630/flake.nix#L47


[2025-11-19 8:03 a.m.] rzioma
ah, this might be the problem `pkgs.stdenv.isLinux`

{Reactions}
😆

[2025-11-19 8:04 a.m.] mole99
You're absolutely right! It's a leftover from a different flake, I completely overlooked it.


[2025-11-19 8:05 a.m.] mole99
Pushing a fix shortly...

{Reactions}
❤️

[2025-11-19 8:09 a.m.] mole99
@ReJ aka Renaldas Zioma You can give it another try now.

{Reactions}
👍

[2025-11-19 11:00 a.m.] rzioma
Worked like a charm. Precheck passed!

{Reactions}
🥳 (2)

[2025-11-19 2:55 p.m.] polyfractal
is there an additional log to get more information about librelane build failures? Trying a test build of what I have to see the end-to-end workflow, and it's failing to wire up power pins to my sram macos (deep in the bowels of my project)

```
Connecting power net VDD to i_chip_core.u_core.tta_0.lsu_fu_0.sram_512x32_0.gf180mcu_fd_ip_sram__sram512x8m8wm1_0/VDD…
[INFO] Made 0 connections.
[06:50:13] ERROR    The following error was encountered while running the flow:  __main__.py:189 
    Odb.SetPowerConnections failed with the following errors:
         add_global_connections failed to make any connections for 'i_chip_core.u_core.tta_0.lsu_fu_0.sram_512x32_0.gf180mcu_fd_ip_sram__sram512x8m8wm1_0/VDD' to VDD. 
```

I've gone through and added the conditional stuff where needed
```
`ifdef USE_POWER_PINS
.VDD  (VDD),
.VSS  (VSS),
`endif
```


[2025-11-19 2:59 p.m.] polyfractal
ah... yosys is deleting my sram module (and a bunch of other stuff)

`Deleting now unused module tta::sram::sram_512x32.  `

{Reactions}
👍

[2025-11-19 3:00 p.m.] polyfractal
ok new question.... why? 😂  I know there's a "keep" annotation to force it, but I don't think any of this is dead code? but I have no idea how synthesizing works


[2025-11-19 3:00 p.m.] mole99
You can find all log files and artifacts in the `librelane/runs/*` directory.
Making the power connections in the RTL is one way, the other is to use `PDN_MACRO_CONNECTIONS`.

{Reactions}
👀

[2025-11-19 3:01 p.m.] polyfractal
aha! `PDN_MACRO_CONNECTIONS` looks much more convenient


[2025-11-19 3:01 p.m.] mole99
Yes, if Yosys removes the SRAM instances, it's because it recognises that none of the outputs are being used. Optoimizing it away 😁


[2025-11-19 3:02 p.m.] mole99
So there is probably an issue in your RTL.


[2025-11-19 3:06 p.m.] polyfractal
hm, it seems to be deleting basically my entire project 😄

{Attachments}
2025-11_media/image-5CCBB.png


[2025-11-19 3:09 p.m.] polyfractal
if a module doesn't have an output, does it get optimized away? I've only wired up inputs to my processor so far (clock, reset, uart loading, etc). so it can run programs but no output


[2025-11-19 3:13 p.m.] tholin
Yes. Yosys checks input to output paths to see what it can optimize away, in my experience.

{Reactions}
👍

[2025-11-19 3:13 p.m.] tholin
If it sees 0 outputs, it just goes "this whole design is just void"


[2025-11-19 3:13 p.m.] polyfractal
argh


[2025-11-19 3:14 p.m.] polyfractal
gotcha, thanks!


[2025-11-19 3:55 p.m.] polyfractal
wired in a temporary output, got the ball moving again! Just to confirm, it looks like the sram macros have to be placed manually on the die? (I see the placement stuff in pdn_cfg.tcl for the two macros in the demo chip_top)


[2025-11-19 3:55 p.m.] polyfractal
and in the config toml


[2025-11-19 3:58 p.m.] mole99
Yes exactly. Placement is defined in `config.yaml` and connection to PDN in `pdn_cfg.tcl`.


[2025-11-19 4:00 p.m.] polyfractal
great, thank you! out of curiosity, is there a reason placements are done by hand instead of being auto-placed by librelane? because they are so large you want a human to do it?


[2025-11-19 4:02 p.m.] polyfractal
(entirely new to this whole world, so lacking a lot of background context 🙂 )


[2025-11-19 4:18 p.m.] mole99
No problem! In our case, manual placement is mostly fine, since there are only a handful of SRAM macros to place.
There was some effort to integrate OpenROAD's automatic macro placer into LibreLane, but it wasn't completed: https://github.com/librelane/librelane/issues/537


[2025-11-19 4:36 p.m.] polyfractal
Makes sense. Juice probably isn't worth the squeeze given the nature of projects here. Easier to do it by hand 🙂


[2025-11-19 4:37 p.m.] _luke_w_
Not my domain (I do frontend) but I can take a couple of guesses at the reasons:

1. Difficult to move large macros later in pnr due to the number of ripups, so there's a high likelihood of automatic placement backing itself into a corner and making the design unroutable.

2.  Desire for consistency between implementation runs -- implementation is usually iterative with new RTL updates  regularly coming in, and you want to know whether issues are due to RTL changes etc as opposed to just the tools having a bad day

3. The power connections to macros like SRAMs etc are usually hand-tuned for best results, and you don't want to rip this up every time

{Reactions}
👏 👍

[2025-11-19 4:37 p.m.] _luke_w_
At least that's for the commercial projects I've worked on. Different dynamics for the new open-source stuff


[2025-11-19 4:38 p.m.] polyfractal
Ahh interesting!


[2025-11-19 4:39 p.m.] 246tnt
I'd love to have suggestions though. Like it would just do a rough electrostatic-style placement  of all standard cells and macro to sort of see how things arrange themselves and make sure I'm not placing those macro at a very inconvenient spot.

{Reactions}
❤️ 💯

[2025-11-19 4:39 p.m.] 246tnt
And then I can lock it there and never move it while refining RTL.


[2025-11-19 4:39 p.m.] _luke_w_
Yeah, like BRAM locking on FPGA 😅


[2025-11-19 4:42 p.m.] _luke_w_
It's a really interesting question, I never thought about it. I just sort of accepted the layout folks at work spent days gently massaging the RAMs into place


[2025-11-19 5:44 p.m.] polyfractal
still not 100% confident yosys didnt optimize away half the design and my laptop locked up so I'm not sure if it actually completed successfully before I had to go to work...but it did finish enough to generate an output GDS 🥳 

so much unused space 😂

{Attachments}
2025-11_media/Screenshot_From_2025-11-19_08-31-14-25A7F.png
2025-11_media/Screenshot_From_2025-11-19_08-30-31-7065F.png

{Reactions}
👍 👏

[2025-11-19 5:56 p.m.] logic_destroyer
My custom ASIC KianV SV32 SoC is now finalized!
RV32IMA + Zicntr/Zicsr/Zifencei/SSTC with full MMU — running uLinux, Linux, and xv6.
With huge help from @Leo Moser (mole99)  — and thanks to 
@Tim 'mithro' Ansell

{Attachments}
2025-11_media/G6IpKybXoAE1ATj-B5552.png
2025-11_media/G6IqYgdXkAAk0MJ-1801C.png

{Reactions}
🥳 (3) ❤️ (4) 👍

[2025-11-19 6:08 p.m.] polyfractal
Started a thread.


[2025-11-19 6:08 p.m.] logic_destroyer
It will run mailine linux/uLinux/XV6 Unix or newer

{Attachments}
2025-11_media/Screenshot_from_2025-11-19_19-01-14-47AD1.png
2025-11_media/Screenshot_from_2025-11-19_19-07-16-CE074.png


[2025-11-19 6:30 p.m.] logic_destroyer
I’ve shared a Python script to render the chip layout from GDS. It’s pretty slow and memory-hungry, but it works. I’ll put it on my GitHub repo later.

{Attachments}
2025-11_media/ieee_export_chip-E6A12.py

{Reactions}
❤️

[2025-11-19 6:33 p.m.] polyfractal
definitely will try that when I get home!


[2025-11-19 6:49 p.m.] tholin
This script generates 3D models and is multithreaded
https://github.com/AvalonSemiconductors/gfmpw1-multi/blob/main/gds2gltf.py

{Reactions}
❤️ (2)

[2025-11-19 6:54 p.m.] logic_destroyer
Richtig geil...danke


[2025-11-19 7:07 p.m.] mole99
And here is my entry in the list of layout renderers. It simply uses KLayout (`pip install klayout`) to render the layout and can therefore load both GDS and OAS. I disabled the filler layers to make the layout stand out better.


[2025-11-19 7:07 p.m.] mole99


{Attachments}
2025-11_media/fabulous_fpga-A6060.png

{Reactions}
❤️ (2)

[2025-11-19 7:07 p.m.] mole99


{Attachments}
2025-11_media/lay2img-E79C6.py


[2025-11-19 7:08 p.m.] mole99
You can run it as `python3 lay2img.py librelane/runs/<timestamp>/final/gds/chip_top.gds image --width 4069 --height 6144` in the root of your repository.


[2025-11-19 7:29 p.m.] tholin
Rendering the AS2650-2 with @asic destroyer ’s script shows some missing wires.

{Attachments}
2025-11_media/chip-7E506.png


[2025-11-19 7:30 p.m.] tholin
Watch your RAM use running this, btw. It gets intense.

{Reactions}
😮 💜

[2025-11-19 8:45 p.m.] mithro_
Super cool!

{Reactions}
❤️

[2025-11-19 8:47 p.m.] mithro_
Started a thread.


[2025-11-19 8:50 p.m.] mithro_
What MCU is that Hazard3?


[2025-11-19 8:52 p.m.] mithro_
Started a thread.


[2025-11-19 8:54 p.m.] mithro_
Automatic macro placement stuff was one of the big things that Google's ML team did for the TPU

{Reactions}
😮

[2025-11-19 8:55 p.m.] mithro_
https://github.com/google-research/circuit_training

{Embed}
https://github.com/google-research/circuit_training
GitHub - google-research/circuit_training
Contribute to google-research/circuit_training development by creating an account on GitHub.
2025-11_media/circuit_training-59747

{Reactions}
😮

[2025-11-19 8:56 p.m.] _luke_w_
Yep, it's Hazard3. There will be at least two of them once I'm done (one for main game firmware and one for audio processing)


[2025-11-19 8:56 p.m.] mithro_
What about one for graphics? 😛


[2025-11-19 8:56 p.m.] _luke_w_
RISCBoy PPU is already quite programmable


[2025-11-19 8:57 p.m.] _luke_w_
and can do affine blits and stuff at 1 pix/clk


[2025-11-19 8:57 p.m.] _luke_w_
so I'm planning to use that with external parallel async SRAM


[2025-11-19 8:57 p.m.] _luke_w_
serial SPI LCD

{Reactions}
❤️ (2)

[2025-11-19 8:57 p.m.] mithro_
@Leo Moser (mole99) - Maybe LibreLane needs container limits to stop locking computers up or something?


[2025-11-19 8:58 p.m.] _luke_w_
would love to do DVI out but if I only have 13 days til final GDS then now is not the time for custom layout 😅

{Reactions}
😮

[2025-11-19 8:59 p.m.] _luke_w_
I'll probably have some std cell-based DCOs on board to play with generating internal clocks but nothing of the quality you'd need for DVI


[2025-11-19 8:59 p.m.] mithro_
Sleep is for the weak 😉


[2025-11-19 8:59 p.m.] _luke_w_
sleep is for two weeks from now


[2025-11-19 9:08 p.m.] tholin
Oh. Tapeout is that soon?


[2025-11-19 9:08 p.m.] tholin
Uhhhhh


[2025-11-19 9:08 p.m.] tholin
Yeah, sleep is indeed for two weeks from now


[2025-11-19 9:11 p.m.] mithro_
Dammit, there is too many cool things to look at in this channel and I need to be finishing the GDS prechecking on platform.wafer.space

{Reactions}
❤️

[2025-11-19 9:13 p.m.] logic_destroyer
Ja, Leo ist richtig geil!

{Attachments}
2025-11_media/chipw-55C88.png

{Reactions}
👏

[2025-11-19 10:24 p.m.] mithro_
We definitely need a gallery or something!

{Reactions}
💯 (2) ❤️ (2)

[2025-11-19 10:54 p.m.] polyfractal
hehe well I think we can blame my laptop for this one. the display/linux controlling it seems to get flaky in memory-constrained circumstances


[2025-11-19 10:54 p.m.] polyfractal
(i also forgot to boost swap before starting it)


[2025-11-20 3:58 p.m.] logic_destroyer
How we can do the same here, excluding gf180mcu_fd_sc_mcu7t5v0__oai21_1  @Leo Moser (mole99) 
https://discordapp.com/channels/1009193568256135208/1438584424554827788


[2025-11-20 5:11 p.m.] mole99 (pinned)
📢 Since the last announcement, a number of important changes have been made to both the PDK and the template.

### PDK

1. [#3](https://github.com/wafer-space/gf180mcu/pull/3): The seal ring generator has been updated.
    - Now actually includes the glass cut.
    - Pplus does not overlap comp, as required by DRC.
2. [#3](https://github.com/wafer-space/gf180mcu/pull/3): Filler generation has been updated to ensure 10um spacing to the seal ring. (This was only a problem for smaller slot sizes).

### Template

1. The core ring now [connects to all vss pads again](https://github.com/wafer-space/gf180mcu-project-template/commit/c119e25b04b1dc3619bcd66cb508f901fd976410). (thanks @tnt!)
2. [#22](https://github.com/wafer-space/gf180mcu-project-template/pull/22): Magic has been updated with fix that significantly reduces peak memory usage.
3. [#21](https://github.com/wafer-space/gf180mcu-project-template/pull/21): The `render-image` Make target renders the GDS layout.
4. [#21](https://github.com/wafer-space/gf180mcu-project-template/pull/21): The CI has been updated.
    - Commands in the nix shell are now only executed once. (thanks @Egor Lukyanchenko!)
    - Create a summary and upload artifacts (gds and image) ([Example](https://github.com/wafer-space/gf180mcu-project-template/actions/runs/19543720582))
5. [#23](https://github.com/wafer-space/gf180mcu-project-template/pull/23): Workaround for a PDN issue.
6. [#24](https://github.com/wafer-space/gf180mcu-project-template/pull/24): Fix antenna violations using `DRT_ANTENNA_REPAIR_ITERS` (disable if any issues occur).
7. The [PDK version](https://github.com/wafer-space/gf180mcu-project-template/commit/b20168925c46fdd292e6084f31bfd8d312379d7e) has been pinned.

Please update your repository in line with the template and clone the latest PDK.

{Reactions}
❤️ (6)

[2025-11-20 6:38 p.m.] mole99
Pinned a message.


[2025-11-20 9:08 p.m.] 246tnt
@Leo Moser (mole99) Is the environment of the leo/gf180 branch of libre lane good ? That's what I'm using since TT is not based at all on the template .


[2025-11-20 10:08 p.m.] mithro_
Does the template have a CHANGELOG file or something? Seems like this would be great to include in that.


[2025-11-20 10:09 p.m.] mithro_
@Leo Moser (mole99) - BTW Did you see that I made the `git describe` version number work?


[2025-11-21 6:04 a.m.] mole99
Yes, the template uses `leo/gf180mcu` as well.
Unfortunately, I still need to rebase from time to time, so any commit hashes that you reference might break.


[2025-11-21 6:10 a.m.] 246tnt
@Leo Moser (mole99) I meant the nix environment of the `leo/gf180mcu`.  Digging a bit I think the magic version is different.


[2025-11-21 6:11 a.m.] rzioma
@Leo Moser (mole99) it might be a red herring, but I think I started getting KLayout DRC violations when running a **precheck**. This started after merging the latest template changes.

I get 12 drc errors and if I read it correctly (`drc.klayout.lyrdb` file) errors are in **sealring**

{Attachments}
2025-11_media/image-52BB2.png


[2025-11-21 6:13 a.m.] mole99
Right! I override the magic version in the template. There is no change in functionality, but it reduces peak RAM usage.
I can update nix-eda as a whole in the `leo/gf180mcu` branch once the latest Yosys hang is fixed.


[2025-11-21 6:15 a.m.] mole99
ReJ, yes that is expected. Sorry! I still need to sync the precheck with the latest changes to the template. I started a run yesterday but didn't get to push the changes yet.


[2025-11-21 6:16 a.m.] mole99
Yes, we can use versions and a changelog for the template from now on.


[2025-11-21 6:17 a.m.] mole99
I would prefer tags in the format `x.y.z`, like in the gf180mcu repository.
I'll update the tag.


[2025-11-21 6:18 a.m.] mithro_
with `git-describe` you get `v0.0-<commits>-<hash>` which some people map to `v0.0.<commits>`


[2025-11-21 6:19 a.m.] mithro_
But I don't really care that enough, do what you prefer 🙂


[2025-11-21 6:20 a.m.] mole99
Yes, `git-describe` is really neat 😁 
I'm generally following the conventions in LibreLane to keep things simple.


[2025-11-21 6:20 a.m.] rzioma
no worries! Happy to hear it is expected

{Reactions}
👍

[2025-11-21 6:30 a.m.] rzioma
Random piece of information, template project also works fine with gf180mcu_fd_sc_mcu**9t**5v0

{Reactions}
👌

[2025-11-21 10:39 a.m.] mole99
You could give this PR a try: https://github.com/wafer-space/gf180mcu-precheck/pull/3

{Embed}
https://github.com/wafer-space/gf180mcu-precheck/pull/3
chore: update precheck to match template by mole99 · Pull Request ...
Update PDK_TAG to 1.1.0
Pin nix-eda to 5.9.0 and override magic to 8.3.576


[2025-11-21 2:28 p.m.] 246tnt
Antenna check is taking forever 😥  It's been an hour and I think it's still at Metal1.


[2025-11-21 2:32 p.m.] tholin
I mean, you do have a lot of Metal1 in the layout if the whole core area has a standard cell grid in it.


[2025-11-21 2:33 p.m.] tholin
My flows are faster than average, I believe, because I only have macros in the top-level and no cell grids.


[2025-11-21 2:33 p.m.] 246tnt
Well the top level of TT doesn't have any cell grid 😅


[2025-11-21 2:34 p.m.] 246tnt
and this test sample is only maybe ... 15~20% filled.


[2025-11-21 2:37 p.m.] tholin
That’s probably already denser than my chip.


[2025-11-21 2:38 p.m.] tholin
But antenna check takes a few seconds for me, so something seems wrong there.


[2025-11-21 2:42 p.m.] 246tnt
Are you talking about KLayout.Antenna or OpenROAD.CheckAntennas step ?


[2025-11-21 2:43 p.m.] tholin
Both, I guess.


[2025-11-21 2:43 p.m.] tholin
A step getting stuck for that long would be quite memorable and I don’t remember anything other than STA and DRC taking forever.


[2025-11-21 2:44 p.m.] 246tnt
Well https://github.com/AvalonSemiconductors/ws-submission-2025/blob/main/librelane/config.yaml#L6
It's disabled in your default config so you'd have to enable it to see it.


[2025-11-21 3:00 p.m.] tholin
I just pushed to the repo


[2025-11-21 3:00 p.m.] tholin
Has my analog pad fixes now


[2025-11-21 5:16 p.m.] logic_destroyer
@tnt Should we enable it?


[2025-11-21 5:17 p.m.] logic_destroyer
@Leo Moser (mole99)

{Attachments}
2025-11_media/Screenshot_from_2025-11-21_18-17-29-8EB09.png


[2025-11-21 5:18 p.m.] 246tnt
It's been running here for 4h ....


[2025-11-21 5:18 p.m.] 246tnt
so I get why it's disabled 😅

{Reactions}
😮

[2025-11-21 7:06 p.m.] _luke_w_
Does anyone know which step in the (template) flow is responsible for adding buffers on a high fanout net? I have a reset net with a fanout of ~1k and in my powered  netlist `./25-openroad-globalplacementskipio/chip_top.pnl.v` still has the reset synchroniser output going directly to all ~1k loads without buffering. This makes the following STAs meaningless because the reset net has like a 100 ns rise time


[2025-11-21 7:46 p.m.] _luke_w_
ah, somewhat answered my own questions:

1. the buffers are added in the `repairdesignpostgpl` step
2. my issue with insane violations was actually because removing the clock variables from your `.yaml` and just defining clocks in your `.sdc` completely skips CTS, so I had like a 450 ns clock rise/fall, and all the flop timings are derated according to slew

{Reactions}
😮 (2)

[2025-11-21 8:30 p.m.] mithro_
Does anyone have a design which currently fails precheck quickly?


[2025-11-21 8:31 p.m.] mithro_
I need some test cases for the manufacturability checking testing


[2025-11-21 8:31 p.m.] tholin
What if you just run precheck against a corrupted GDSII file so it fails just loading?


[2025-11-21 8:38 p.m.] mithro_
Yeah, I can do those ones pretty easy, I'm other an otherwise compliant design that just has DRC violations.


[2025-11-21 11:52 p.m.] mithro_
@Leo Moser (mole99) - I believe your pull request to the precheck is now merged and the docker image got updated.


[2025-11-22 7:48 a.m.] 246tnt
Antenna check is going on 18h, so I think I'll give up on it 😅


[2025-11-22 8:12 a.m.] mole99
Thanks!


[2025-11-22 8:14 a.m.] mole99
Yeah, I also remember it taking forever during my testing 😅
For the second shuttle, I can look into rewriting/improving the KLayout antenna checks (there have been some updates to KLayout), or using a magic antenna check. But I don't see how we can possibly enforce zero antenna violations on the first shuttle.


[2025-11-22 8:53 a.m.] rzioma



[2025-11-22 1:04 p.m.] noritsunaimamura
I ran a precheck on the GDS with PDK updated to 1.1.0 and new Filler and Sealing.
It has been successfully completed.
It took 4 hours and 36 minutes on Ubuntu24.04. The PC specifications are: "Ryzen 3 Pro 4350G (4-core, 8-thread) & MEM: 64GB".

However, when running on WSL, Klayout crashed when signals such as SIGKILL were sent  or no response. 
When I used about 14GB of memory, Klayout has crashed.

- Precheck Log
https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/tree/main/precheck_log/RUN_2025-11-22_16-51-07
- Project GitHub
https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1

{Attachments}
2025-11_media/precheck_3rd_OK-9A554.png


[2025-11-22 1:57 p.m.] 246tnt
Interesting I'm getting quite a few `Error while reading cell "tt_gf_wrapper" (byte position 137203656): Warning: cell "Metal1_fill_cell" placed on top of   itself.  Ignoring the extra one.` during the pre-check, maybe something's wrong somewhere in fill generation ?


[2025-11-22 2:10 p.m.] mole99
You can ignore those for now. From what Tim had looked into it, these are most likely real overlapping cells generated by KLayout during filler generation.
I still need to prepare a reproducible for Matthias.

{Reactions}
👌 (2)

[2025-11-22 2:47 p.m.] mole99
Hi @Noritsuna Imamura, with which error does KLayout crash?


[2025-11-22 2:49 p.m.] noritsunaimamura
It's like this.

{Attachments}
2025-11_media/precheck_3rd_klayout_crash01-87886.png
2025-11_media/precheck_3rd_klayout_crash02-A8A84.png
2025-11_media/precheck_3rd_klayout_crash03-DD445.png
2025-11_media/precheck_3rd_klayout_crash04-C1E15.png
2025-11_media/precheck_3rd_klayout_crash05-367CB.png


[2025-11-22 2:59 p.m.] mole99
Could you please open an issue in the [precheck repo](https://github.com/wafer-space/gf180mcu-precheck) with all the details and a link to the GDS? Unfortunately, I cannot look into it right now, but I would like to try and see if it crashes on my end as well.

You should be able find the full KLayout log in the run directory.

{Reactions}
🆗 done

[2025-11-22 3:02 p.m.] 246tnt
It worries me a bit that 30 min into the execution of the klayout drc step, it hasn't even started with the "Executing rule XXX" phase of the check 🤔


[2025-11-22 5:20 p.m.] tholin
Is there a way for me to run the KLayout DRC checks on a GDSII file without running the full chip_top flow? I just want to know if my DACs still have DRC errors without waiting 4+ hours for DRC to run on the full chip.


[2025-11-22 5:22 p.m.] 246tnt
`klayout -b -zz -r ${PDK_ROOT}/gf180mcuD/libs.tech/klayout/tech/drc/gf180mcu.drc -rd input=your.gds -rd report=drc.klayout.lyrdb -rd feol=True -rd beol=True -rd dummy=True -rd offgrid=True -rd conn_drc=True -rd wedge=True -rd run_mode=deep -rd thr=16`


[2025-11-22 5:23 p.m.] 246tnt
That's the command run by the pre-check.


[2025-11-22 5:30 p.m.] tholin
Its so annoying to me that I can spend days putting something together in magic until its DRC clean, and then KLayout comes in "Actshually, there is 107 DRC errors"

{Reactions}
😮

[2025-11-22 5:39 p.m.] 246tnt
I think that's pretty much the deal of being on this first run is that you're beta testing stuff ...


[2025-11-22 5:43 p.m.] 246tnt
Although I'm looking at some of the error in KLayout and ... they might be false positive.

{Reactions}
😮

[2025-11-22 5:44 p.m.] tholin
I have tons of DRC errors for this. So uhm. Is it too long? Too short? What is the limit?

{Attachments}
2025-11_media/image-F7AF9.png


[2025-11-22 5:45 p.m.] tholin
Am I about to have to dive into some source code just to know what this is about?


[2025-11-22 5:46 p.m.] tholin
No errors in magic

{Attachments}
2025-11_media/image-DC49F.png


[2025-11-22 5:47 p.m.] 246tnt
Yes, looking at that now. I think there is a missing marker layer.

{Reactions}
😢

[2025-11-22 5:47 p.m.] 246tnt
5V and 6V transistors have no difference except the channel length.


[2025-11-22 5:48 p.m.] tholin
What is the marker layer?


[2025-11-22 5:48 p.m.] 246tnt
And there is a marker layer (purely informational, doesn't mean anything for manufacturing) to tell klayout that a given transistor is meant to be 5V and not 6V.


[2025-11-22 5:48 p.m.] 246tnt
v5_xtor


[2025-11-22 5:50 p.m.] 246tnt
112/1


[2025-11-22 5:50 p.m.] tholin
`string MASKHINTS_V5_XTOR` does not have an effect. Will actually have to draw this in KLayout.


[2025-11-22 5:51 p.m.] 246tnt
Yeah, MASKHINTS only works if support for maskhints for that particular layer is in the tech file.


[2025-11-22 5:51 p.m.] 246tnt
@Tim Edwards it seems `magic` isn't creating that layer at all, I see no support for writing it in the tech file ?


[2025-11-22 5:51 p.m.] tholin
But also, these are supposed to be 6V devices


[2025-11-22 5:52 p.m.] tholin
But also, magic extracts them as 5V?


[2025-11-22 5:52 p.m.] tholin
There is weird things going on here


[2025-11-22 5:59 p.m.] tholin
Oh no, the transistors are indeed too small for 6V devices - and magic doesn’t see a problem with that.


[2025-11-22 5:59 p.m.] tholin
In other words, I’d like to report a bug...


[2025-11-22 6:08 p.m.] 246tnt
I'm guessing the `mv` devices (which are the ones used in your design) are meant to be the 5V one and the `hv` would be the 6V ones.


[2025-11-22 6:10 p.m.] 246tnt
Ah no, I think magic doesn't differentiate between 5V and 6V devices at all.


[2025-11-22 6:10 p.m.] 246tnt
both are `mvnfet` / `mvpfet` and it's just whatever length you use that will dictate which one it is ...


[2025-11-22 6:17 p.m.] tholin
hv is 10V


[2025-11-22 6:18 p.m.] tholin
GF180mcu has LV, MV 5V, MV 6V, Native Vt, HV LDMOS


[2025-11-22 6:18 p.m.] tholin
Which are 3.3V, 5V, 6V, 6V and 10V respectively.


[2025-11-22 6:20 p.m.] tholin
Here is another DRC error that I’m seeing a lot of in KLayout but that isn’t represented in magic.

{Attachments}
2025-11_media/image-C4F8A.png


[2025-11-22 6:20 p.m.] tholin
Even though it totally could be.


[2025-11-22 6:25 p.m.] 246tnt
I think there are also drc not checked by klayout because anything wider than 30u must be slitted and it didn't spot that.


[2025-11-22 6:42 p.m.] 246tnt
@Leo Moser (mole99) I think the KLayout deck has issues.


[2025-11-22 6:42 p.m.] 246tnt
"M3.2b : Space to wide Metal3 (length & width > 10um) : 0.3µm"

{Attachments}
2025-11_media/2025-11-22_551x273_scrot-95CE6.png


[2025-11-22 6:43 p.m.] 246tnt
That's a 0.28u trace ... hardly "wide Metal3".

{Reactions}
😮

[2025-11-22 7:01 p.m.] rtimothyedwards_19428
@Tholin :  Sorry, I was not following this conversation until Sylvain flagged me.
I keep trying to remind people that the magic DRC deck for GF180MCU was designed in a hurry for what was a digital-only tapeout from Efabless.  I made a "good first pass" at the analog rules and layers but there were no analog designs to validate it with.  I have made some corrections since then, but it is more or less in the same state.  I suppose the same goes for the klayout deck---No real validation in practice.


[2025-11-22 7:11 p.m.] rtimothyedwards_19428
@Tholin :  I found the GF handling of "5V" devices to be awkward and looked for some method to be consistent.  It has never seemed reasonable to me that the same device can be either "5V" or "6V", and requires a marker layer to specify the _intent_ of it.  But mostly the issue of the way it is currently implemented in magic comes from early on struggling with what was _meant_ by a 5V or 6V transistor, along with largely unreadable documentation trying (badly) to explain it.  There were no 5V devices in the device model files originally.  I added those to the model files recently.  I could certainly redo the magic tech file to separate the 5V and 6V transistor types (now that there is a device model for each of them) and use the V5_XTOR ("FET5VDEF" in the magic techfile) to distinguish them (and apply the device length rules separately for each of them).


[2025-11-22 7:13 p.m.] 246tnt
IMHO it's fine to only have `mv` to represent 5V/6V , but the `V5_XTOR` layer still need to be generated if length is too small to be 6V to comply with the DRC requirement ...  I'm not sure if that's something doable in the magic tech file ?


[2025-11-22 7:13 p.m.] rtimothyedwards_19428
So it's not so much a bug as an implementation decision.  Given that (at the time I implemented it) there was only one device model, I just had magic extract that one device model and discarded the information from the V5_XTOR mask.  Either way, it's the same device, same model (my 5V model is just a copy of the 6V model, with a restriction on device length applied to the 6V model).


[2025-11-22 7:15 p.m.] rtimothyedwards_19428
@tnt :  It can be done.  I assume the purpose is to have magic-generated GDS pass DRC in klayout?


[2025-11-22 7:15 p.m.] 246tnt
Yes. But also potentially any DRC GF themselves are running since this is in the design manual.


[2025-11-22 7:16 p.m.] rtimothyedwards_19428
But I think that just implementing, say, "mvpfet" = 5V pfet and "hvpfet" = 6V pfet would be more consistent with the PDK overall.


[2025-11-22 7:16 p.m.] 246tnt
Sure, I have no strong opinion on that.


[2025-11-22 7:17 p.m.] 246tnt
The 10V one are `ld` if I read the tech file correctly.


[2025-11-22 7:34 p.m.] rtimothyedwards_19428
Are there any published rules for V5_XTOR?  I can't find any in the open PDK documentation.  In the vendor libraries, it appears to cover entire cells, although I would assume it is only meaningful over the gate of the device.


[2025-11-22 7:48 p.m.] rtimothyedwards_19428
@Tholin :  The magic tech file _does_ implement rule V1.3d;  where do you see it not flagging the rule?  (Note that the DRC documentation has no rule"V1.3d", only "V1.3".  The "d" seems to have been invented by Mabrains when they make the klayout DRC deck.)


[2025-11-22 7:49 p.m.] 246tnt
https://gf180mcu-pdk.readthedocs.io/en/latest/physical_verification/design_manual/drm_07_08.html


[2025-11-22 7:49 p.m.] 246tnt
AFAICT it's just the gate over comp that needs to be covered.


[2025-11-22 7:52 p.m.] rtimothyedwards_19428
@tnt : Thanks, I missed PL.11.  But PL.12 suggests that the diffusion as well as the gate must be covered.


[2025-11-22 7:53 p.m.] rtimothyedwards_19428
Rule PL.12 might be intended to prevent mixing 5V and 6V devices in the same circuit.


[2025-11-22 7:53 p.m.] 246tnt
At least the klayout DRC only checks the gate.


[2025-11-22 7:53 p.m.] rtimothyedwards_19428
But GF might flag PL.12.


[2025-11-22 7:56 p.m.] 246tnt
Yes. Without exactly a drawing for what PL.12 means, I'm not sure tbh.


[2025-11-22 7:57 p.m.] 246tnt
I like also how there is a drawing for PL.19 but then no PL.19 rule 😅


[2025-11-22 7:57 p.m.] rtimothyedwards_19428
I'll start counting the issues in the rules and illustrations, and get back to you next week.

{Reactions}
🤣

[2025-11-22 8:04 p.m.] rtimothyedwards_19428
It occurs to me that there must (?) also be "cap_nmos_05v0", "cap_pmos_05v0", "cap_nmos_05v0_b", and "cap_pmos_05v0_b" devices, but the devices themselves are just modeled as ideal capacitors (?!) and the models have no restriction on length and width.  Also, moscap-connected transistors in the SRAM are just transistors in the netlist.  Maybe the moscap device should just be quietly removed from the PDK. . .


[2025-11-22 8:27 p.m.] rtimothyedwards_19428
@tnt :  Okay, I have reworked the GF tech file for magic, and pushed the change.  There is also a pending commit to add the 3.3V SRAM library to the open_pdks installation of GF180MCU, so it will all be mirrored to github by tomorrow.

{Reactions}
👌 (3)

[2025-11-22 8:28 p.m.] 246tnt
Oh wow, that was fast 😅


[2025-11-22 8:28 p.m.] 246tnt
Thanks !


[2025-11-22 8:30 p.m.] _luke_w_
Is anyone else using clock gates (ICGs) in their designs? I'm getting ~2ns SRAM address hold violations with CPU on a gated clock and SRAM on an ungated version of the same clock. I saw TritonCTS had a `-balance_levels` switch (off by default, enabled by `CTS_BALANCE_LEVELS: True`), but it didn't seem to help with overall clock skew:

> -balance_levels Attempt to keep a similar number of levels in the clock tree across non-register cells (e.g., clock-gate or inverter). The default value is False, and the allowed values are bool.


[2025-11-22 8:34 p.m.] _luke_w_
Related note: based on a tip in the Caravel report I found I could reduce overall clock skew by about 40% (2.8 -> 1.7 ns in post-CTS STA) by forcing Triton to always use the largest available clock buffer. Is there any reason not to make this the default? If you're tight on timing then it may even save area overall as you should need fewer fixups and resizes

```
# Force use of chonky bois to reduce clock skew (default list is 2, 4, 8)
CTS_CLK_BUFFERS:
  - "gf180mcu_fd_sc_mcu7t5v0__clkbuf_16"
```


[2025-11-22 9:12 p.m.] _luke_w_
Actually there is something suspicious in my CTS report:

```
Total number of Clock Roots: 6.
```

I have four defined clocks with two gates on one of those clocks. If I rebuild with the ICG cells removed, I get

```
Total number of Clock Roots: 4.
```
Is Triton treating each gate as a new root? Normally ICGs are just buffers for CTS purposes, and you'd explicitly define a root if you wanted a root


[2025-11-22 9:12 p.m.] polyfractal
re: DRC, I assumed these were checks that GF provided, but I guess they are "implemented" based on written rules that GF publishes? What happens if we submit a design that validates fine but doesn't meet GF's internal checks?


[2025-11-22 9:13 p.m.] polyfractal
or do they just YOLO it and you get back a bad wafer?


[2025-11-22 9:13 p.m.] 246tnt
GF definitely didn't provide the decks for KLayout and Magic 😅


[2025-11-22 9:14 p.m.] 246tnt
If it's the same as for Sky130, the fab runs their own deck and comes backs with a list of violations that need fixing.


[2025-11-22 9:15 p.m.] 246tnt
They usually only bother reporting the MR ( Manufacturing Rule ), i.e. the rules that would actually prevent manufacturing the thing at all.  There are also a bunch of rules that are not MR. i.e. they would affect the performance or function, but are not manufacturing risk, so they don't care so much, it's sort of your problem.


[2025-11-22 9:17 p.m.] polyfractal
👍  makes sense, thanks


[2025-11-23 1:03 a.m.] rtimothyedwards_19428
Actually I don't think GF had any concept of "MR" rules (or rather, no _documented_ "MR" rule set);  we (Efabless) went through the usual iteration of them sending us a document highlighting all the errors, and coming to an agreement on which rules to waive and which rules to pass back to the user to fix.  Because the two tapeouts were all-digital, we didn't have any user project errors that I recall.  The errors were things in the GF IP (like the I/O cells) which were being flagged by GF's own DRC deck;  none of which would meet the definition of an "MR" rule.

{Reactions}
👍

[2025-11-23 11:36 a.m.] rebelmike
Yes, the default is to find roots automatically. In OpenLane 2 there didn’t seem to be a way to explicitly specify roots, I don’t know if things have improved since then.

If the gated clock only feeds a small number of cells, I believe you can avoid getting a full clock tree built for it by explicitly instantiating a buffer after the gate, which should reduce the skew.


[2025-11-23 12:33 p.m.] urish
Started a thread.


[2025-11-23 1:15 p.m.] mole99
That's right. From the first round of DRC with GF, it seems the whole rule deck is checked, including recommended rules.


[2025-11-23 1:16 p.m.] 246tnt
Do they allow to waive the recommended ?


[2025-11-23 1:17 p.m.] mole99
Yes. But it's going to be a back and forth.


[2025-11-23 1:19 p.m.] mole99
In other words, if we don't have any DRC violations, we don't need a waiver file, and submitting to the foundry would be faster and less complicated.


[2025-11-23 1:29 p.m.] 246tnt
Does the klayout deck test for recommended rules ?


[2025-11-23 1:34 p.m.] mole99
The ones that were violated weren't checked at least. I would need to go through the whole deck to see which are implemented and which are not.
The other way is to go backwards: see which DRC rules are triggered and trying to fix them/add them to the deck.
With actual designs in the reticle we should see a more complete list of DRC violations that are not yet caught by the open source rule decks.


[2025-11-23 11:35 p.m.] asc9742
Hi all, have people had success running LVS of their designs including the generated padframe? Would like some assurance it is possible before committing to running the long netgen LVS script.


[2025-11-23 11:37 p.m.] tholin
I should do that sometime. I am super worried about VDD/VSS shorts and I believe LVS could detect them.


[2025-11-23 11:37 p.m.] tholin
Though I’m not sure.


[2025-11-24 1:03 a.m.] tholin
First DRC, LVS, STA clean GDSII

{Attachments}
2025-11_media/test_black-85010.png

{Reactions}
👏 (6)

[2025-11-24 1:09 a.m.] asc9742
What flow are you using for LVS? Did you create your own padframe schematic using the io spice files from GF or is there a way to get it from the project template?


[2025-11-24 1:10 a.m.] tholin
The LVS that runs when you do `make librelane`


[2025-11-24 1:11 a.m.] asc9742
I see.


[2025-11-24 1:12 a.m.] bailey8889
@Tholin Be aware that the librelane LVS abstracts any macros and standard cells.
I can advise on a setup to run full device level LVS along with soft connection and ERC checks.


[2025-11-24 1:13 a.m.] tholin
I’m mostly just interested in checking for VDD/VSS shorts

{Reactions}
👍

[2025-11-24 1:13 a.m.] tholin
I accidentally created such shorts before and the flow did not fail.


[2025-11-24 12:06 p.m.] _luke_w_
Is it possible to get librelane installed as an editable package (like a submodule of my repo) but still use the rest of the `nix-shell` setup? I wanted to look at adding a yosys extraction for mux + flop -> scan flop but librelane is quite hardcoded.


[2025-11-24 12:10 p.m.] tholin
I have a similar complaint. nix-shell currently pulls binaries, but I’d actually like the option to have everything be built from source.


[2025-11-24 12:22 p.m.] 246tnt
@Tholin you can just remove the cachex entry I think. Then it will be everything from source.


[2025-11-24 12:36 p.m.] mole99
You can clone the [leo/gf180mcu](https://github.com/librelane/librelane/tree/leo/gf180mcu) branch (same one used for wafer.space). Next, you can make any changes inside the repo and then start LibreLane with `nix-shell`. 
That's basically the same step as in: https://librelane.readthedocs.io/en/latest/installation/nix_installation/installation_linux.html#cloning-librelane
You can also apply patches in the in the Nix flake of the template, but it's a bit finicky.


[2025-11-24 12:37 p.m.] mole99
That's what Nix is for. It builds all the binaries for you. In the case of the wafer.space template we point to a specific branch of LibreLane and the binaries are already cached.


[2025-11-24 12:56 p.m.] _luke_w_
ah, so the shell I get from running `nix-shell` in that branch of the librelane repo is a suitable environment for running the makefile in the project template? If so then got it, thanks


[2025-11-24 12:57 p.m.] _luke_w_
I probably would move to putting patches in the flake (should just be a few lines to add a flag to pass an extraction file) but I need to develop the patch 🙂

{Reactions}
👍

[2025-11-24 1:05 p.m.] mole99
Yes. The project template uses that branch with an override to get a newer magic version. But it should also work with the magic version specified in LibreLane.


[2025-11-24 4:14 p.m.] polyfractal
very silly newbie question: does part of the librelane build process spit out the max frequency the chip is expected to run at? or is there some other way to tell?


[2025-11-24 4:26 p.m.] mole99
Yes, you can find the report in the console or inside `54-openroad-stapostpnr/summary.rpt`. 
It contains a list of all corners and whether there are any setup violations for the target frequency. If there is a setup violation at a corner, it means that you will not be able to run the chip at the target frequency at that particular corner (PVT - Process, Voltage and Temperature). Using the setup worst slack, you can calculate the maximum frequency for each corner, which could even be above the target frequency.


[2025-11-24 4:34 p.m.] rzioma
There is also `54-openroad-stapostpnr\nom_tt_025C_3v30\clock.rpt` (and actually for each corner) which tells you `fmax` for that corner.


[2025-11-24 5:15 p.m.] polyfractal
thanks!


[2025-11-24 5:20 p.m.] polyfractal
aha, and found the target frequency in the yaml. cheers!

{Reactions}
🙌

[2025-11-25 7:11 p.m.] _luke_w_
Anyone else getting occasional crashes in the detailed router? e.g.

```
 [INFO DRT-0076]   Complete 3000 pins.
Signal 6 received
Stack trace:
 0# handler(int) in /nix/store/g74fz644z0828i5dksxm95mzdb91aq2g-openroad-2025-10-28/bin/.openroad-wrapped
 1# _sigtramp in /usr/lib/system/libsystem_platform.dylib
 2# pthread_kill in /usr/lib/system/libsystem_pthread.dylib
 3# abort in /usr/lib/system/libsystem_c.dylib
 4# malloc_vreport in /usr/lib/system/libsystem_malloc.dylib
 5# malloc_report in /usr/lib/system/libsystem_malloc.dylib
 6# ___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED in /usr/lib/system/libsystem_malloc.dylib
```

Probably  won't have time to file reproducibles til after tapeout but I've made note of my git hashes. I'll just back out the RTL changes for now. Wondering if there is any way to work around it without undoing RTL commits


[2025-11-25 8:29 p.m.] logic_destroyer
Wie hast Du das geschafft?


[2025-11-25 8:30 p.m.] _luke_w_
Keine Ahnung


[2025-11-25 8:46 p.m.] logic_destroyer
MacOSX?


[2025-11-25 8:57 p.m.] _luke_w_
Yeah it is on MacOS on an M4. The tools do just seem to behave slightly weirdly there, like I also get klayout/magic XORs and I'm not the only person to see that (but fine on Linux)


[2025-11-25 9:02 p.m.] logic_destroyer
I don’t have these issues on my Debian or Ubuntu machines. Leo and I have generated over 60 chips in the last 3 weeks.


[2025-11-25 9:03 p.m.] _luke_w_
yep I'll go back to my Linux box when I need to close DRC. M4 is just faster

{Reactions}
🎉

[2025-11-26 7:44 a.m.] mole99
Started a thread.


[2025-11-26 11:28 a.m.] rzioma
Those CAP violations, I think I am getting them even with vanilla project template, how serious are they?

(So far I couldn’t find a way to get rid of them)


[2025-11-26 11:28 a.m.] rzioma


{Attachments}
2025-11_media/image0-CE086.jpg


[2025-11-26 11:34 a.m.] 246tnt
If they don't lead to slew rate violation, then, they really don't matter AFAIK.

{Reactions}
👍

[2025-11-26 11:37 a.m.] tholin
I heard there is a way to use the 9-track cells now?


[2025-11-26 11:37 a.m.] tholin
I’d like to use them in the multiplexer of my die, since that thing is very performance critical.


[2025-11-26 11:46 a.m.] 246tnt
You didn't use your cell library ? Or do you want 5V support ?


[2025-11-26 11:57 a.m.] tholin
I need 5V support

{Reactions}
👍

[2025-11-26 11:59 a.m.] mole99
You should be able to change it via: `STD_CELL_LIBRARY: gf180mcu_fd_sc_mcu9t5v0`. But there have been no changes to the 9t library.


[2025-11-26 12:07 p.m.] 246tnt
Several people hardened TT projects with 9t without issues.


[2025-11-26 12:29 p.m.] _luke_w_
...so by omission you're saying there *have* been changes to the 7t library? I'm using 9t, do I need those changes?


[2025-11-26 12:33 p.m.] _luke_w_
The thing I came here to post was: there are several bugs in the vendor RAM model that seem to be simulation related and not functional details of the RAM macro. What's our policy on patching the models? In particular:

* It drops the first access because it fails to correctly initialise `cen_dly` and `cen_flag_dly`; can be fixed by just using `always_comb` to get a time=0 evaluation
* It registers its inputs on a 100 ps delayed version of the clock, making it unsuitable for RTL simulations which just have an NBA delay on the input for the next cycle


[2025-11-26 12:43 p.m.] mole99
No, there have been no changes to the 7t or 9t library :) I only mentioned this because Tholin wrote: "I heard there is a way to use the 9-track cells **now**?" It already worked before.


[2025-11-26 12:44 p.m.] _luke_w_
ah. phew, ok


[2025-11-26 12:44 p.m.] _luke_w_
heart rate returning to normal

{Reactions}
😁

[2025-11-26 12:45 p.m.] mole99
I think it would be great to fix those issues. Preferably in the FOSSi upstream repository.


[2025-11-26 12:46 p.m.] mole99
Let me just quickly check where open_pdks gets the SRAM sources from, I don't see a FOSSi fork for that.


[2025-11-26 12:47 p.m.] _luke_w_
Ok sure, added to my list of post-tapeout tasks 🙂 actually I'm curious, is anyone else using the vendor RAM models for RTL sims? I have a behavioural model in my RAM wrapper which I was using until now, but I wanted to run RTL sims with all my manually-instantiated cells enabled so that pulled in the vendor model.

{Reactions}
👌

[2025-11-26 12:47 p.m.] mole99
Aha, it's still the original google repo: https://github.com/RTimothyEdwards/open_pdks/blob/486fb8633c3d95ae475a5ccd68d0066c25919bb5/gf180mcu/Makefile.in#L184


[2025-11-26 12:47 p.m.] tholin
The analog IO pads are still broken and cannot be used with LibreLane, but the fix is easy. Should be possible to upstream.


[2025-11-26 12:48 p.m.] mole99
Yes, I did use it for some very simple tests.


[2025-11-26 12:49 p.m.] _luke_w_
Huh. And were you driving the inputs from posedge flops or did you have some behavioural delay and/or negedge stuff going on?


[2025-11-26 12:54 p.m.] mole99
There are two things going on in my case:

I was testing the FPGA fabric in my chip and to prevent logic loops during configuration I added delays to it.
In the testbench I was waiting two clock cycles before I read the output. I don't remember if the two clock cycles were really necessary, but I was simply happy to get the correct data out again. 😆 
I didn't have time to take a closer look since then.


[2025-11-26 12:54 p.m.] _luke_w_
One of the issues I think I saw (not fully diagnosed) is a read where the address changes on the posedge can give you the data from the address after the posedge


[2025-11-26 12:55 p.m.] _luke_w_
ah ok if the address is stable over the edge then you won't see issues


[2025-11-26 12:55 p.m.] _luke_w_
I'm always nervous about patching vendor models but this one does seem quite broken

{Reactions}
👌

[2025-11-26 1:03 p.m.] mole99
Started a thread.


[2025-11-26 1:48 p.m.] mole99 (pinned)
📢 Project Template Update!

Version [1.1.2](https://github.com/wafer-space/gf180mcu-project-template/releases/tag/1.1.2) has been tagged. Notable updates include:

- Support for different slot sizes ◻️◽▫️
  - This will likely be an option for future shuttles. For the first shuttle, however, smaller slot sizes are still experimental.
  - You can try this out by setting the `SLOT` variable. See the [README](https://github.com/wafer-space/gf180mcu-project-template?tab=readme-ov-file#choosing-a-different-slot-size) for more information.
  - The CI now also runs for all slot sizes in the upstream repo `wafer-space/gf180mcu-project-template`: https://github.com/wafer-space/gf180mcu-project-template/actions/runs/19697592187
- Better SRAM power connections ⚡
  - `pdn_cfg.tcl`: better connectivity for the SRAM orientations. Please make sure to update your PDN config!
- The PDK has been updated to 1.1.2
  - NP.12 and PP.12 reimplemented
  - Wide metal check fixed

Please update your projects and PDKs.
The latest precheck tag is [1.0.1](https://github.com/wafer-space/gf180mcu-precheck/releases/tag/1.0.1).

{Reactions}
🎉 (5)

[2025-11-26 1:49 p.m.] mole99
Pinned a message.


[2025-11-26 1:56 p.m.] 246tnt
Will quarter slots be 1/4 of the price ? 😅


[2025-11-26 2:02 p.m.] mole99
I assume the cost of packaging will not go down by much. However, regarding the area, that's for @Tim 'mithro' Ansell to say.


[2025-11-26 4:59 p.m.] rzioma
▫️<-- that would be great for retro stuff (Z80)!


[2025-11-26 5:01 p.m.] rzioma
@Tholin I am hardening with both mcu7t5v0 and mcu9t5v0 in parallel. I need (imho ridiculously high) **0.5** slack margins for HOLD violation in case of 7t, but otherwise both work and pass precheck.
And with @htamas help, we tried both in TT.


[2025-11-26 5:34 p.m.] polyfractal
I've been using the vendor verilog as well. I assumed it was correct (looking to be a mistake?) and didn't trust myself to write a correct behavior stub. 😅  I've been getting data in/out but if there was a timing discrepancy I probably chalked it up to my own timing issues and just worked around it in my code


[2025-11-26 7:50 p.m.] _luke_w_
Oh interesting. Do you have the address changing every cycle, on a posedge?


[2025-11-26 8:00 p.m.] polyfractal
yep. I'm using it for both instruction memory and generic SRAM. so most (all?) of the tests are probably incrementing the address each cycle to fetch a new instruction. the few tests that check branching also jump around but don't hold the same address over multiple clocks. and the general sram tests are just random accesses as well


[2025-11-26 8:01 p.m.] _luke_w_
Huhhhh


[2025-11-26 8:01 p.m.] polyfractal
I do have a somewhat mystery clock delay at the beginning of the core bootup, which I attributed to my own jank code. will have to check when I get home but iirc it's two cycles before things start looking correct


[2025-11-26 8:01 p.m.] _luke_w_
and you're using the RAM model in both gate sim and behavioural RTL sim?


[2025-11-26 8:02 p.m.] polyfractal
emmm, maybe? I'm using Spade HDL (transpiles to verilog), so copied/pasted the macro verilog into the spade setup so it can reference for tests. 

Not sure if that's gate sim or behavioural? probably behavioural (cocotb tests)


[2025-11-26 8:03 p.m.] _luke_w_
yeah, behavioural. Ok thanks, that's useful information, I need to look at my sims a bit more 🙂 definitely some weird stuff going on in that model

{Reactions}
👍

[2025-11-26 8:04 p.m.] polyfractal
i'm praying it's not toooooo terribly off, otherwise my chip is totally not gonna work 😅


[2025-11-26 8:04 p.m.] _luke_w_
gate sim would be a simulation of the synthesised (or post-place etc) netlist instead of your (transpiled) source code


[2025-11-26 8:04 p.m.] polyfractal
aha


[2025-11-26 8:04 p.m.] polyfractal
i should probably figure out how to add some basic tests for that...


[2025-11-26 8:05 p.m.] _luke_w_
There is already some setup for it in the template's cocotb harness, if you look through where this variable is used in `chip_top_tb.py`:
```
gl = os.getenv("GL", False)
```


[2025-11-26 8:06 p.m.] _luke_w_
in theory just set that flag. in practice, dragons abound

{Reactions}
😁

[2025-11-26 8:07 p.m.] polyfractal
ooh interesting. so theoretically the same cocotb tests would run and should match the behavioural testing pre-synth? will try it out when i get home


[2025-11-26 8:08 p.m.] _luke_w_
that is the theory. you can have new issues in gate sim like Xs propagating in places they didn't before, but the netlist should be equivalent to your RTL


[2025-11-26 8:09 p.m.] polyfractal
rad! that would make me a lot more confident, especially if I can get it run before the payment deadline 😅


[2025-11-26 8:09 p.m.] polyfractal
cheers for the info!


[2025-11-26 9:12 p.m.] polyfractal
unrelated: i rented a beefy'ish droplet to run the process flow. turns out despite being memory-short on my laptop, fewer/faster cores still win over more slower cores and lots of memory 🙁


[2025-11-26 9:13 p.m.] polyfractal
looks like quite a few steps are single-core operations. alas


[2025-11-26 9:34 p.m.] _luke_w_
Yep, the fastest machine in my house for running this ASIC flow is my macbook air, annoyingly


[2025-11-26 9:36 p.m.] _luke_w_
it's worse for some commercial ASIC tools because vendors will apply per-core licensing so the optimal play is to buy the fastest single-core machine you can find

{Reactions}
💀

[2025-11-26 10:41 p.m.] mithro_
Gaming machine trend to do well

{Reactions}
🎉

[2025-11-26 11:42 p.m.] mithro_
Good way to justify a new machine 😉


[2025-11-27 1:22 a.m.] mithro_
https://claude.ai/public/artifacts/77fed888-f1c3-431e-a4d1-7ec42a556241

{Embed}
https://claude.ai/public/artifacts/77fed888-f1c3-431e-a4d1-7ec42a556241
Best Servers for EDA Performance Under $100/Month 2024
Compare dedicated servers vs cloud instances for single-threaded EDA workloads. Hetzner's i9-13900 delivers 40% better performance than AWS/GCP at $91/month.
2025-11_media/claude_ogimage-1F4D7.png


[2025-11-27 2:15 a.m.] trev5514
"To be compatible with the default breakout PCB, do not change any of the power or ground pads."

Just to make sure I understand correctly, I **can** do the wirebond option if I drop a few pwr/gnd pins, I just have to bring my own PCB?


[2025-11-27 2:20 a.m.] trev5514
Also, it's been a minute since I used the template, I pulled it in October and have not been following updates. Whoever added the automatic pads is amazing. I remember seeing the pad instances individually laid out on the config.yaml. This is night and day, bravo!


[2025-11-27 8:55 a.m.] mole99
Hi Trevor, if you want to use the CoB bonding option:

1. Do not change the number of pads on any side. This ensures that the bondpad placement stays exactly the same.
2. The VSS pads are shorted on the default breakout PCB. This is why you should not change any of the ground pins.
3. As for whether you can provide your own PCB, @Andrew Wingate should be able to answer that.


[2025-11-27 8:55 a.m.] mole99
I'm glad you appreciate the updated template. Having all pad instances individually was really too much 😄


[2025-11-27 9:30 a.m.] noritsunaimamura
Our GDS had errors in the zero polygon and wide metal. (The new check item is functioning properly.)
We fixed our GDS, and the new precheck was successful.
https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/raw/main/images/precheck_5th_OK.png 

- precheck log
https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/tree/main/precheck_log/RUN_2025-11-27_10-26-31
- GDS
https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/blob/main/gds/ISHI-KAI_WS_RUN1.zip

{Reactions}
👏 (2)

[2025-11-27 2:24 p.m.] _luke_w_
I'm getting a couple of hundred klayout DRCs in the standard cell region. They're all `CO.6a (i) Metal1 (< 0.34um) end-of-line overlap contact`. Only other mention I found on this discord was https://discord.com/channels/1361349522684510449/1424739011846471740/1424745841952030860. Any ideas what could be causing that? I'm using 9-track cells if that helps


[2025-11-27 2:25 p.m.] _luke_w_
I have to confess I've not merged the project template for about a week and a half, so I could be missing some updates


[2025-11-27 2:29 p.m.] _luke_w_
here is one point it flagged between 33/0 and 34/0 (presumably m1 and contact). 1 box = 20 nm

{Attachments}
2025-11_media/image-2BF79.png


[2025-11-27 2:31 p.m.] 246tnt
https://gf180mcu-pdk.readthedocs.io/en/latest/physical_verification/design_manual/drm_07_13.html


[2025-11-27 2:31 p.m.] 246tnt
I'm trying to understand the rule but ... it's not super clear TBH 😅


[2025-11-27 2:32 p.m.] 246tnt
Can you zoom out a bit ? Does the line "end" there ?


[2025-11-27 2:32 p.m.] tholin
I know this rule!


[2025-11-27 2:32 p.m.] tholin
It needs some metal right here

{Attachments}
2025-11_media/image-E2FAB.png


[2025-11-27 2:33 p.m.] tholin
There is a separate contact overlap minimum for traces that are exactly the minimum-width and at the end of their line.


[2025-11-27 2:33 p.m.] 246tnt
Well KLayout seems convinced it does, but I'm not sure it's not an error in the KLayout deck.
For me I see that as falling in the CO.6b case.


[2025-11-27 2:35 p.m.] tholin
When a trace terminates at a contact, then the edge opposite to where the trace extends is the "end of line"

{Attachments}
2025-11_media/image-C2731.png


[2025-11-27 2:36 p.m.] tholin
In these cases, additional overlap is needed


[2025-11-27 2:36 p.m.] tholin
Which is only partially true for the example shown here, but it seems its still covered by the rule.


[2025-11-27 2:37 p.m.] tholin
For now, I suggest adding the affected standard cells to the exclude lists.


[2025-11-27 2:38 p.m.] 246tnt
OTOH that cell library was made by GF so when there is doubt, I tend to suspect the KLayout deck more.


[2025-11-27 2:38 p.m.] tholin
Actually, the overlap shown here is *tiny.* I doubt this would pass even magic DRC.


[2025-11-27 2:39 p.m.] 246tnt
CO.6b rule is specially for that case that says if the overlap is less than 40 nm you can "compensate" by having a bigger overlap on the adjacent sides.


[2025-11-27 2:39 p.m.] 246tnt
But I agree that excluding the affected cell is the easiest thing to do given the time constraints.


[2025-11-27 2:52 p.m.] _luke_w_
This is a zoom-out of the same region. It doesn't end, just necks down

{Attachments}
2025-11_media/image-BD91D.png


[2025-11-27 2:53 p.m.] _luke_w_
actually this looks like it is inside of one of the std cells 🤔


[2025-11-27 2:54 p.m.] _luke_w_
yeah, it's an icgtp_1


[2025-11-27 2:56 p.m.] _luke_w_
circled it here. from: https://gf180mcu-pdk.readthedocs.io/en/latest/digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/cells/icgtp/gf180mcu_fd_sc_mcu9t5v0__icgtp_1.html

{Attachments}
2025-11_media/image-90D97.png


[2025-11-27 2:57 p.m.] _luke_w_
it's clean with magic DRC (apart from all the overlapping filler cells)


[2025-11-27 3:03 p.m.] _luke_w_
Yeah I clicked through all 200 CO.6a warnings and they're all the same spot in the `icgtp_1`. I also have four `PL.3a : Space on COMP/Field: 0.24µm` which are just for the four orientations of the same cell. Inclined to waive given it's a foundry cell...


[2025-11-27 3:03 p.m.] 246tnt
Yes, so for me that's valid and the KLayout DRC is an error.

{Reactions}
👍

[2025-11-27 3:04 p.m.] _luke_w_
The points flagged by PL.3a are across this neck on 30/0 in the `icgtp_1` cell:

{Attachments}
2025-11_media/image-5D744.png


[2025-11-27 3:06 p.m.] _luke_w_
My pattern recognition monkey brain is telling me this is just the two-gate poly on the left-hand side of the cell in my picture


[2025-11-27 3:08 p.m.] _luke_w_
Oh that's definitely a bug right? It's treating it as multiple polygons and saying they violate spacing

{Attachments}
2025-11_media/image-9873B.png


[2025-11-27 3:10 p.m.] 246tnt
Yeah, that seems weird to me too. How wide is the neck down ?


[2025-11-27 3:11 p.m.] _luke_w_
in x it's about 0.22 um


[2025-11-27 3:12 p.m.] _luke_w_
I wonder if it's actually flagging the y distance between the two horizontals, since it's a spacing rule


[2025-11-27 3:12 p.m.] _luke_w_
(the y distance is around 0.10 um)


[2025-11-27 3:14 p.m.] 246tnt
I looked at the cell, it all seems good to me.


[2025-11-27 3:16 p.m.] _luke_w_
nice, thank you


[2025-11-27 3:16 p.m.] _luke_w_
I think I'm DRC clean then (for now)


[2025-11-27 3:17 p.m.] _luke_w_
is it possible to waive a specific cell for the klayout checks? (in librelane)


[2025-11-27 3:18 p.m.] mole99
Thanks for the investigation, that makes things easy for me 😁

The easiest path forward is to exclude this cell from synthesis and PnR. Does `_icgtp_2` (if it exists) have the same issues?


[2025-11-27 3:20 p.m.] _luke_w_
1 and 2 both have the metal neck around the via. 4 does not


[2025-11-27 3:20 p.m.] _luke_w_
they all seem to have the same kink in the poly


[2025-11-27 3:20 p.m.] _luke_w_
I'd rather not remove clock gating as it would hurt QoR quite a bit given this cell library lacks DFFEs


[2025-11-27 3:21 p.m.] _luke_w_
also I think the map file for lighter is buried deep inside librelane or openroad somewhere


[2025-11-27 3:22 p.m.] trev5514
Has anyone used Slang and gotten the power ports to work? It looks like yosys-slang doesn't support inout ports?


[2025-11-27 3:24 p.m.] mole99
It does support them, but I think you need to keep the hierarchy, if I recall correctly. See here: https://github.com/mole99/greyhound-ihp/blob/2a2cf3e284a2f2486b71e48212d01458f55e8a0e/config.yaml#L103

{Reactions}
👍

[2025-11-27 3:27 p.m.] trev5514
Looks like that worked, thanks!

{Reactions}
👌

[2025-11-27 3:28 p.m.] mole99
Alright, I absolutely get your point. The problem with waiving is, there is currently no way to ignore a cell in KLayout with the current setup afaik.
In the worst case I can take a manual look at the submission and waive those errors.
Ideally, I would find the time to fix them before the tapeout, unfortunately time is currently rare.


[2025-11-27 3:29 p.m.] mole99
Could you open an issue detailing both issues (collecting the info from above)?


[2025-11-27 3:39 p.m.] _luke_w_
ok, in that case is there a way to add a `grep -v` or so to the log lint in librelane?


[2025-11-27 3:40 p.m.] _luke_w_
Separately I get magic DRC errors for overlapping identical filler cells (I think other people have seen this) and this is harmless afaict but prevents me from running `make copy-final`


[2025-11-27 3:42 p.m.] logic_destroyer
What causes  icgtp?


[2025-11-27 3:42 p.m.] _luke_w_
either clock gating inference or manual instantiation (I have both)


[2025-11-27 3:43 p.m.] logic_destroyer
hmm


[2025-11-27 3:43 p.m.] mole99
LibreLane counts the DRC errors in the `.lydrb` that was produced by KLayout. So I don't think that would help. You would need a filter inside of that function.


[2025-11-27 3:44 p.m.] _luke_w_
how have people waived DRCs on past tapeouts?


[2025-11-27 3:44 p.m.] _luke_w_
(I'm filing an issue with all of the pictures)

{Reactions}
👍

[2025-11-27 3:45 p.m.] mole99
I don't think that's the issue. The default template should also have these overlap issues, but they should be ignored by LibreLane afaik.
If you get any DRC violations, LibreLane won't create the `final` folder.


[2025-11-27 3:46 p.m.] logic_destroyer
These are my primitives for GF180.

{Attachments}
2025-11_media/image-3DC8F.png


[2025-11-27 3:48 p.m.] _luke_w_
ohhh you're right, I actually have some new magic DRCs:

```
Poly overlap of contact < 0.065um (CO.3)
MV N-Diffusion overlap of contact < 0.065um (CO.4)
```


[2025-11-27 3:55 p.m.] _luke_w_
Here's one of the CO.3 violations: contact poly overlap here in `dffrnq_4`. For scale the thick part of that poly is 500 nm across.

{Attachments}
2025-11_media/image-D21CF.png

{Reactions}
😮

[2025-11-27 4:03 p.m.] _luke_w_
You won't have any clock gating cells  if you don't explicitly enable it. Also you got lucky and your `dffrnq` (flop with async reset) are all drive=1.

{Reactions}
😮

[2025-11-27 4:31 p.m.] logic_destroyer
Oh, I was using some negedge resetn signals. I’ve removed them now.


[2025-11-27 4:34 p.m.] logic_destroyer
stage 06

{Attachments}
2025-11_media/image-2606E.png


[2025-11-27 4:38 p.m.] _luke_w_
I wrote up those DRC issues with some pictures: https://github.com/wafer-space/gf180mcu-project-template/issues/34

{Embed}
https://github.com/wafer-space/gf180mcu-project-template/issues/34
9-track foundry standard cells are not clean with KLayout or Magic ...
KLayout violations The clock gating cell icgtp_1 is flagged with the following by klayout: CO.6a : (i) Metal1 (&lt; 0.34um) end-of-line overlap contact (Applies to all &lt; 0.34µm wide metal lines,...
2025-11_media/34-64502

{Reactions}
🎉

[2025-11-27 4:39 p.m.] tholin
Last time, I brought you the neverending LVS run, today, I bring you the Synthesis run from hell:

{Attachments}
2025-11_media/image-5B673.png

{Reactions}
😩 ⁉️

[2025-11-27 4:39 p.m.] _luke_w_
if you have no async reset in your design then how do you know that resetting your chip puts all the pads into tristate?


[2025-11-27 4:40 p.m.] _luke_w_
is this still a gate ROM? I found ABC was thinking incredibly hard about my 256-byte ROM and it helped to have a pipestage after it


[2025-11-27 4:40 p.m.] tholin
No, this is something different.


[2025-11-27 4:40 p.m.] tholin
What does ABC even stand for?


[2025-11-27 4:42 p.m.] 246tnt
https://people.eecs.berkeley.edu/~alanmi/abc/


[2025-11-27 4:42 p.m.] 246tnt
That's a logic mapper used by yosyis.


[2025-11-27 4:50 p.m.] logic_destroyer
https://gf180mcu-pdk.readthedocs.io/en/latest/IPs/IO/gf180mcu_fd_io/tri_state_2.html


[2025-11-27 4:53 p.m.] _luke_w_
yes that's a tristate buffer?


[2025-11-27 4:54 p.m.] _luke_w_
is there an async path from your reset input to OE or do you have to clock the chip to stop it from driving its outputs in reset?


[2025-11-27 4:58 p.m.] logic_destroyer
I wrote a DM


[2025-11-27 5:34 p.m.] logic_destroyer
Do we need a power-on reset chip?


[2025-11-27 5:34 p.m.] _luke_w_
A PoR would be nice for future tapeouts. I'm just treating my reset input pad as a PoR.


[2025-11-27 5:35 p.m.] logic_destroyer
sonst macht das alles kein Sinn im Chip


[2025-11-27 5:38 p.m.] _luke_w_
tristating all of your outputs when held in reset is pretty common and not just a PoR thing. For example it lets you drive other signals into those PCB traces on your board when you're debugging. If you have two chips on a bidirectional bus and they **both** enable their outputs at reset then that creates drive contention. Etc


[2025-11-27 5:39 p.m.] _luke_w_
on a real board your chip may be held in reset for some time with its clock stopped while power rails are sequenced


[2025-11-27 5:56 p.m.] mole99
Quick question: instead of a synchronizer, Hirosh could use an async apply and sync remove circuit for the reset. The ouput of this circuit gates the bidir OE and also goes into his circuit. So when you apply the reset, the bidir pads are immediately in a safe state. If you remove the reset, his circuit still works as before. Did I understand this correctly?


[2025-11-27 5:57 p.m.] _luke_w_
Yep that seems like it would work

{Reactions}
👍

[2025-11-27 5:58 p.m.] _luke_w_
so you have an async reset, which is derived from the reset pad input with an async reset synchroniser

{Reactions}
👌

[2025-11-27 5:58 p.m.] _luke_w_
that resets the pads and also goes into another synchroniser which generates the sync reset used for your digital logic


[2025-11-27 5:59 p.m.] _luke_w_
something like that would work. I don't think he necessarily needs to make any changes but for a "production" chip it's certainly unusual to drive outputs at start of day


[2025-11-27 6:00 p.m.] mole99
Why do you need another synchronizer afterwards? The reset signal is then already asynchronously removed.


[2025-11-27 6:01 p.m.] _luke_w_
depends how your resets are constrained but if you allow async transitions to propagate to a sync reset net then that usually needs a timing exception


[2025-11-27 6:01 p.m.] _luke_w_
even if it is async apply, sync remove


[2025-11-27 6:01 p.m.] mole99
I see, thanks!


[2025-11-27 6:01 p.m.] mole99
And another one: Without a PoR the outputs can still be in an unknown state during power up, right? Holding the reset low doesn't help in that case, as the input pads could be doing anything?


[2025-11-27 6:03 p.m.] _luke_w_
I don't have a simple answer to that and don't fully understand it myself. There's a question there about how the pads behave during ramp-up, and how the logic cells behave at much less than nominal voltage


[2025-11-27 6:03 p.m.] _luke_w_
If you have an async path from the reset that disables the pads then any spurious enable during power supply ramp will at least be a short-lived transient


[2025-11-27 6:04 p.m.] mole99
"It's complicated" is what I thought as well 😄


[2025-11-27 6:04 p.m.] _luke_w_
my answer as a digital designer is values other than 1 and 0 don't exist and can't hurt me

{Reactions}
😄 (2) ❤️

[2025-11-27 6:06 p.m.] mole99
Thanks for all the tips. It's great to have so many people with different experiences around. There's something for everyone to learn 👏


[2025-11-27 6:09 p.m.] _luke_w_
yeah this project has been a huge learning curve for me. Thanks for all the help, hope I'm not too annoying with flagging issues


[2025-11-27 6:10 p.m.] mole99
On the contrary, it is greatly appreciated!


[2025-11-27 6:10 p.m.] logic_destroyer
@LukeW thank you


[2025-11-27 6:10 p.m.] logic_destroyer


{Attachments}
2025-11_media/image-1022A.png


[2025-11-27 6:11 p.m.] logic_destroyer


{Attachments}
2025-11_media/image-0447D.png


[2025-11-27 6:11 p.m.] logic_destroyer
@Leo Moser (mole99) thank you 🙂


[2025-11-27 6:11 p.m.] mole99
Now only the synchronizer to the core is missing 👍


[2025-11-27 6:12 p.m.] _luke_w_
Functionally looks good, might look funny in STA though. I would add a false path between the synchroniser output and the pad OE signals


[2025-11-27 6:13 p.m.] logic_destroyer
is inside the soc

{Reactions}
👌

[2025-11-27 6:17 p.m.] logic_destroyer
Could I use (* async_reg="true" *) reg [1:0] ff;


[2025-11-27 6:23 p.m.] logic_destroyer
Maybe @LukeW Do you have an example to set false path. I think I need it for 2 signals 😉


[2025-11-27 6:24 p.m.] logic_destroyer
https://github.com/Wren6991/RISCBoy-180/blob/bb4540d8b1ee8493448395a5b010c80b37377010/librelane/chip_top.sdc


[2025-11-27 6:27 p.m.] _luke_w_
Most of them come from this wildcard:

```tcl
# Apply RTL-inserted false path constraints (setup/hold only, still constrain slew)
set_false_path -setup -hold -through [get_pins *.magic_falsepath_anchor_u/Z]
```

And then there is an RTL module that inserts magic buffers for the constraints:

https://github.com/Wren6991/RISCBoy-180/blob/bb4540d8b1ee8493448395a5b010c80b37377010/hdl/cells/falsepath_anchor.v


[2025-11-27 6:31 p.m.] _luke_w_
You can also do it directly in the sdc, something like `set_false_path -setup -hold -from sync_reg_name_here/Q -to *_PAD/OE` but it's a bit cumbersome in this flow because flops don't have predictable names unless you instantiate them yourself

{Reactions}
🎉

[2025-11-27 6:51 p.m.] logic_destroyer
Hi-z

{Attachments}
2025-11_media/image-1B123.png


[2025-11-27 6:54 p.m.] mole99 (pinned)
⚙️ Update to the precheck, version [1.2.1](https://github.com/wafer-space/gf180mcu-precheck/releases/tag/1.2.1).

- Zero area polygons are checked.
- The layout origin and size are checked depending on the selected slot size, the default is `1x1`.
- Ensure that `PDK_ROOT` and `PDK` are set.

{Reactions}
❤️ (2)

[2025-11-27 6:54 p.m.] mole99
Pinned a message.


[2025-11-27 7:00 p.m.] urish
will try in on ttgf0p2


[2025-11-27 7:01 p.m.] urish
https://github.com/TinyTapeout/tinytapeout-gf-0p2/actions/runs/19745733739


[2025-11-27 7:33 p.m.] logic_destroyer
Should I apply the same approach to the FPGA as well?


[2025-11-27 8:26 p.m.] _luke_w_
You can? FPGAs normally already handle this with their own PoR, before your bitstream ever loads

{Reactions}
👍🏻

[2025-11-27 8:30 p.m.] logic_destroyer
Yes, that's what I thought, which is why I wanted to ask you again.


[2025-11-27 9:54 p.m.] logic_destroyer


{Attachments}
2025-11_media/image-EA595.png


[2025-11-27 11:02 p.m.] noritsunaimamura
Update to the precheck, version 1.2.1.
All Green!
https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/raw/main/images/precheck_6th_OK.png

{Embed}
https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/raw/main/images/precheck_6th_OK.png
2025-11_media/precheck_6th_OK-BEC4F.png


[2025-11-28 12:03 a.m.] tholin
Is there a "routing keep-out" layer I can define in KLayout?


[2025-11-28 12:12 a.m.] h.tamas
You can add a macro with an empty .gds and a .lef file with an `OBS` block containing a rectangle on the right metal layer. I don't think klayout can write .lef files but they are easy to write by hand.


[2025-11-28 12:17 a.m.] h.tamas
```
VERSION 5.7 ;
  NOWIREEXTENSIONATPIN ON ;
  DIVIDERCHAR "/" ;
  BUSBITCHARS "[]" ;
MACRO whatever
  CLASS COVER ;
  FOREIGN whatever ;
  ORIGIN 0.000 0.000 ;
  SIZE 100.000 BY 100.000 ;
  OBS
    LAYER Metal2 ;
    RECT 25.000 25.000 75.000 75.000 ;
  END
END whatever
END LIBRARY
```


[2025-11-28 12:24 a.m.] bailey8889
@Tholin you may already be aware, but I believe you can also specify obstruction areas in the openlane config file.

{Reactions}
👍

[2025-11-28 12:48 a.m.] tholin
Sorry, let me rephrase: how can I block *just* routing while leaving the PDN free to do what it wants?

{Reactions}
👍

[2025-11-28 1:00 a.m.] polyfractal
is there somewhere in the flow that lists overall stats like total transistors, etc?


[2025-11-28 1:08 a.m.] _luke_w_
Every step in a run should have a `state_out.json`. Have a look at the `metrics` key in the JSON file, maybe that has what you're looking for?


[2025-11-28 1:09 a.m.] _luke_w_
```
        "design__instance__count__stdcell": 116005,
        "design__instance__area__stdcell": 2878000,
        "design__instance__count__macros": 28,
        "design__instance__area__macros": 5360940,
        "design__instance__count__padcells": 1136,
        "design__instance__area__padcells": 5271000,
        "design__instance__count__cover": 0,
        "design__instance__area__cover": 0,
        "design__instance__utilization": 0.63858,
        "design__instance__utilization__stdcell": 0.381646,
        "design__rows": 3408,
        "design__rows:GF018hv5v_green_sc9": 3408,
        "design__sites": 2496942,
        "design__sites:GF018hv5v_green_sc9": 2496942,
        "design__instance__count__class:macro": 28,
        "design__instance__area__class:macro": 5360940,
        "design__instance__count__class:input_pad": 3,
        "design__instance__area__class:input_pad": 78750,
        "design__instance__count__class:input_output_pad": 53,
        "design__instance__area__class:input_output_pad": 1391250,
        "design__instance__count__class:power_pad": 18,
        "design__instance__area__class:power_pad": 472500,
        "design__instance__count__class:tie_cell": 383,
        "design__instance__area__class:tie_cell": 4323.92,
        "design__instance__count__class:buffer": 2135,
        "design__instance__area__class:buffer": 42671.9,
        "design__instance__count__class:inverter": 7722,
        "design__instance__area__class:inverter": 89255.6,
        "design__instance__count__class:clock_gate_cell": 613,
        "design__instance__area__class:clock_gate_cell": 50137.1,
        "design__instance__count__class:sequential_cell": 7291,
        "design__instance__area__class:sequential_cell": 568677,
        "design__instance__count__class:multi_input_combinational_cell": 48145,
        "design__instance__area__class:multi_input_combinational_cell": 912403,
```

Maybe more detail than you wanted 🙂


[2025-11-28 1:11 a.m.] _luke_w_
Doesn't go down to transistor count unfortunately because the design flow is working with bigger units than transistors. If you wanted a transistor count you could write some script to scrape the transistors from the std cell spice netlist `gf180mcu/gf180mcuD/libs.ref/gf180mcu_fd_sc_mcu7t5v0/spice/gf180mcu_fd_sc_mcu7t5v0.spice` and then multiply by instance counts scraped from your netlist

{Reactions}
👍

[2025-11-28 3:57 a.m.] greg.hashtag.9468
When using the slang frontend, I'm seeing errors, this line in config.yaml suggested this was a tested option. Maybe I'm the first to try it 😅 
```
# Enable plugin for better SystemVerilog support
USE_SLANG: True
```

The error seems to be slang's handling of the VDD/VSS connecting in the netlist it passes through to yosys. Not liking the `inout` type.
```
use_slang
6. Executing SLANG frontend.
src/chip_core.sv:12:17: error: direction 'InOut' on inlined port connection unsupported
inout  wire VDD,
^
src/chip_core.sv:13:17: error: direction 'InOut' on inlined port connection unsupported
inout  wire VSS,
^
src/chip_core.sv:32:39: error: direction 'InOut' on inlined port connection unsupported
inout  wire [NUM_ANALOG_PADS-1:0] analog  // Analog
^
ERROR: Compilation failed 
```


[2025-11-28 3:59 a.m.] greg.hashtag.9468
I was seeing this with a custom design that's using some systemverilog feature to carry arrays of signals into a module. Which plain yosys does not understand.
But I have confirmed the issue with the vanilla template.


[2025-11-28 4:07 a.m.] _luke_w_
apparently there is a workaround: https://discord.com/channels/1361349522684510449/1423348662318272592/1443623510667821167

{Reactions}
👍

[2025-11-28 4:09 a.m.] greg.hashtag.9468
Ahh, I should have searched this channel before asking :doh:


[2025-11-28 5:18 a.m.] greg.hashtag.9468
New error, but this time I'm pretty sure it's related to my RTL 
```
6. Executing SLANG frontend.
ERROR: Assert `count_id(cell->name) == 0' failed in kernel/rtlil.cc:2624.
```


[2025-11-28 5:58 a.m.] trev5514
Has anyone used Fault with this template? I've never used it before and hoping for an easy integration, any tips would be welcome!


[2025-11-28 7:06 a.m.] mole99
It is probably more advisable to create a macro with DFT support and integrate this macro into the chip.

The successor to Fault is Difetto: https://github.com/donn/difetto/tree/main


[2025-11-28 7:34 a.m.] trev5514
Thanks I'll look into that!


[2025-11-28 7:35 a.m.] trev5514
Has anyone seen this?

`XOR: missing required input 'mag_gds'`

I get it at the end of a run during the KLayout vs. Magic XOR step.


[2025-11-28 7:36 a.m.] 246tnt
Did you disable the magic streamout step by any chance ?


[2025-11-28 7:39 a.m.] trev5514
I pulled a fresh template earlier today and haven't changed the config except for macros and to use SLANG.


[2025-11-28 7:43 a.m.] trev5514
```tcl
meta:
  version: 3
  flow: Chip
  substituting_steps:
    # Disable KLayout DRC
    #KLayout.DRC: null
    #Checker.KLayoutDRC: null

    # Disable KLayout antenna check
    KLayout.Antenna: null
    Checker.KLayoutAntenna: null

    # Disable KLayout density check
    #KLayout.Density: null
    #Checker.KLayoutDensity: null

    # Save time during development
    # Enable for sign-off
    #OpenROAD.IRDropReport: null
    #Magic.DRC: null
    #Checker.MagicDRC: null
    #KLayout.XOR: null
    #Netgen.LVS: null
    #Checker.LVS: null

PRIMARY_GDSII_STREAMOUT_TOOL: klayout
```

This is some relevant lines from the config.yaml.


[2025-11-28 7:48 a.m.] mole99
Are you using macOS by any chance?
@LukeW Didn't you encounter this error as well?


[2025-11-28 7:51 a.m.] 246tnt
In the `runs` directory, do you see it running magic stream out ?


[2025-11-28 7:57 a.m.] trev5514
Yes, I am on a mac.


[2025-11-28 8:00 a.m.] trev5514
Yes... Interestingly the log shows:

Up at the top (not sure if this is important just caught my eye):
`Using NULL graphics device.`

Then at the bottom:
`Cannot open .../librelane/runs/RUN_2025-11-28_00-08-28/73-magic-streamout/chip_top.magic.gds to write GDS-II stream output`

I only have a `chip_top.mag` , no .magic.gds.


[2025-11-28 8:06 a.m.] 246tnt
NULL is normal, just means it's running in console, no GUI output.


[2025-11-28 8:06 a.m.] 246tnt
The bottom one is not normal 🙂


[2025-11-28 8:21 a.m.] mole99
Now I remember, you likely reached the limit of max open file handlers!
You can try to increase it with `ulimit`. A proper fix would be for LibreLane to tell magic it doesn't have to lock the files. It's on my list...

{Reactions}
❤️

[2025-11-28 9:05 a.m.] urish
Passed!

{Reactions}
❤️ (2)

[2025-11-28 9:11 a.m.] mithro_
You could probably use the prebuilt docker containers @ https://github.com/wafer-space/gf180mcu-precheck/pkgs/container/gf180mcu-precheck

{Embed}
https://github.com/wafer-space/gf180mcu-precheck/pkgs/container/gf180mcu-precheck
Build software better, together
GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.
2025-11_media/github-logo-55c5b9a1fe52-4FC66.png

{Embed}
https://github.com/wafer-space/gf180mcu-precheck/pkgs/container/gf180mcu-precheck
2025-11_media/github-mark-57519b92ca4e-A0C13.png

{Embed}
https://github.com/wafer-space/gf180mcu-precheck/pkgs/container/gf180mcu-precheck
2025-11_media/github-octocat-13c86b8b336d-42CA8.png


[2025-11-28 9:15 a.m.] bailey8889
Thanks, I'll check it out.


[2025-11-28 9:36 a.m.] trev5514
I maxed my limit, and unfortunately, the error still persists.


[2025-11-28 2:41 p.m.] mole99
For now, it might be the best path forward to use a Linux machine to build the complete ASIC.
Unfortunately, there seem to be a number of differences between the Linux and macOS versions of the tools.

{Reactions}
👍

[2025-11-28 2:46 p.m.] _luke_w_
The issue I had was on Ubuntu 24 LTS. I was getting a zero bytes magic GDS because magic failed to open some of the IP mag files. I found my soft open file limit was 1024 and increasing it with `ulimit -Sn 4096` solved that particular issue.

On MacOS I have a different issue which is that I get actual XORs between KLayout and Magic GDS. I didn't diagnose that, I just stopped using MacOS for now (it also tends to crash in the detailed router).


[2025-11-28 2:48 p.m.] 246tnt
Possibly related is someone on sky130 had klayout on MacOS hallucinate DRC violations that weren't there ( and don't show up when running klayout on linux ).


[2025-11-28 2:57 p.m.] mole99
Yes, he created an issue: https://github.com/KLayout/klayout/issues/2231


[2025-11-28 3:06 p.m.] polyfractal
this'll do, thanks! I assume the cells used in a macro are counted in the instance stdcell count? was trying to get a sense for how many transistors/cells were in my logic but not the sram macros. Not really important, just curious 🙂


[2025-11-28 3:07 p.m.] _luke_w_
I think the SRAM macros are just counted as whole macros, so they don't appear in the cell instance counts there. They're usually custom layout, not standard cells

{Reactions}
❤️

[2025-11-28 3:08 p.m.] _luke_w_
for a rough transistor count estimate just multiply the number of SRAM bits by 6


[2025-11-28 3:10 p.m.] polyfractal
oh awesome, that's perfect. cheers


[2025-11-28 9:07 p.m.] logic_destroyer
I’d like to share how GF180mcu KianV ASIC SoC will behave.
It currently runs on an FPGA at 30 MHz, using the same setup we have on wafer.space GF180mcu.
We’ll show a short demo over the serial console; the rest will be  over Telnet, we support spi/ethernet on the chip.
The design will become a tiny Linux network SoC. It already runs XV6 (the MIT teaching Unix) , and μLinux.

{Attachments}
2025-11_media/Screencast_from_2025-11-28_22-01-42-D65CD.webm

{Reactions}
🎉 (4) 🇱 🇮 🇳 🇺 🇽

[2025-11-28 9:55 p.m.] logic_destroyer
Kernel 6.18.0-rc5 riscv32

{Attachments}
2025-11_media/image-E0320.png

{Reactions}
❤️ (2) 🇼 🇦 🇫 🇪 🇷

[2025-11-28 11:15 p.m.] mithro_
Started a thread.


[2025-11-28 11:16 p.m.] mithro_
How are you running the precheck on GitHub Actions? Are you using custom runners? I thought that the precheck was too resource heavy for the actions?


[2025-11-28 11:19 p.m.] mithro_
@carlfk / @asic destroyer - Do you think we could get this running on fpgas.online? I'm guessing the issue is SDRAM controller and https://fpgas.online only having Arty boards with DDR3? 

@carlfk - Did I ever end up giving you ulx3s boards or did they all end up in my shipping container? I think I had them as the 3rd priority FPGAs to get onto https://fpgas.online behind the NeTV2 boards?


[2025-11-28 11:21 p.m.] carlfk
I don't think you gave me or I have any ulx3s

{Reactions}
😮

[2025-11-28 11:22 p.m.] mithro_
@asic destroyer - I assume you are using ulx3s boards?


[2025-11-28 11:22 p.m.] logic_destroyer
Yes, best board on earth 🙂


[2025-11-28 11:25 p.m.] logic_destroyer
The FPGA design targets multiple boards.

ASIC  and ULX3s  differs  only in the top-level  module.
The underlying hierarchy remains identical in behavior.


[2025-11-28 11:26 p.m.] logic_destroyer
I need only 32MiB SDRAM, I could built top for ARTIX7, ecp5, cyclone, gatemate, ...


[2025-11-28 11:27 p.m.] logic_destroyer
@Tim 'mithro' Ansell @GoranMahovlic sells ulx3s on https://www.ebay.de/itm/385678851894?_skw=ulx3s&itmmeta=01KB6CNS3DATNKFMD1BADXY67H&hash=item59cc403f36:g:EbYAAOSwdBpjvJtw&itmprp=enc%3AAQAKAAAA4FkggFvd1GGDu0w3yXCmi1fwK1STpgN5pylpk0DDHI4qgOMwtWMnwHddsMaZ--aq3DW7e3EB8j26DYmkpKx441kiUMlJEmXbwEMNnBW7WPlmo61%2FPLyYGXGuiYPxwJymjdgnkgawKFn0aUZLj6ciIwu7V5bQdM2l3YaVkC3ZJ5Ai6WuIb0GcpLzbmOTZbEXIHHz3VEGlr8alajydtJqUfaQeXUS74VKBttzRMap%2FJEPuQYDY5W%2BG2KqT6kCAC5MM1Z9NmjHYoWPaGpRD9kQiXn3N3r%2B83W3rk92piNCIaEjn%7Ctkp%3ABk9SR-KS18zZZg

{Embed}
https://www.ebay.de/itm/385678851894?_skw=ulx3s&itmmeta=01KB6CNS3DATNKFMD1BADXY67H&hash=item59cc403f36:g:EbYAAOSwdBpjvJtw&itmprp=enc%3AAQAKAAAA4FkggFvd1GGDu0w3yXCmi1fwK1STpgN5pylpk0DDHI4qgOMwtWMnwHddsMaZ--aq3DW7e3EB8j26DYmkpKx441kiUMlJEmXbwEMNnBW7WPlmo61%2FPLyYGXGuiYPxwJymjdgnkgawKFn0aUZLj6ciIwu7V5bQdM2l3YaVkC3ZJ5Ai6WuIb0GcpLzbmOTZbEXIHHz3VEGlr8alajydtJqUfaQeXUS74VKBttzRMap%2FJEPuQYDY5W%2BG2KqT6kCAC5MM1Z9NmjHYoWPaGpRD9kQiXn3N3r%2B83W3rk92piNCIaEjn%7Ctkp%3ABk9SR-KS18zZZg
ULX3S with ECP5 12F Entwicklungsboard Open Source 32 MB RAM  | eBay.de
ULX3S - A powerful, open hardware ECP5 FPGA dev board. Finally, if you are just starting out with FPGAs, you can use the Arduino IDE to program ULX3S in seconds. FPGA: Lattice ECP5. LFE5U-12F-6BG381I (12K LUT).
2025-11_media/s-l400-E3C0D.jpg


[2025-11-28 11:29 p.m.] mithro_
I had a video chat with @GoranMahovlic a while back and he offered to help with supplying the ulx3s for https://fpgas.online and wafer.space related stuff

{Reactions}
🎉

[2025-11-28 11:32 p.m.] logic_destroyer
The designs fits into 12f


[2025-11-28 11:34 p.m.] logic_destroyer
Do you want ASIC-like behavior, or can I optimize it further? I can add more cache (more ways), more TLBs, and still clock it at 70 MHz on the ECP5.


[2025-11-28 11:35 p.m.] logic_destroyer
I support these models

{Attachments}
2025-11_media/image-68F5E.png


[2025-11-28 11:36 p.m.] logic_destroyer
But after the deadline, I’m going to heavily rework this repo so it’s based on the ASIC design. After that, I’ll probably only support ULX3S, iCEPi, and the QMTech Wukong.


[2025-11-29 2:32 a.m.] polyfractal
some dumb pad questions 🙃  :

- we can reconfigure input vs bidirectional pads to suit our design, right? should we leave VDD/VSS alone?
- what's the actual difference between input and bidir? bidir just has extra stuff for sourcing output current or something? (i.e. why would you prefer input over bidir set to input)
- what should I do with unused pins? Set to bidir and bidir_ie = 0 "ignore pad" ?


[2025-11-29 2:38 a.m.] _luke_w_
* yes, all pads are the same size (the two bidi types, the input-only, and the power pads) so changing pad types does not change the pad coordinates
* VDD/VSS need to be left alone to stay bond-compatible with the COBs; you can move them around if you don't rely on the default COB setup
* One case you'd prefer input is for a global reset input, because you don't want that to spuriously enable its output driver during power-up. Pretty much everything else can be bidi
* Tying off A = IE = OE = 0 is one option, you could also put a small hardcoded UART that prints a rude message


[2025-11-29 2:42 a.m.] polyfractal
awesome, thanks!

And lol at the rude message 😄


[2025-11-29 2:45 a.m.] greg.hashtag.9468
Or any message. Spare chips could then be used to advertise "BreakingTaps!\r\n" at 9600bps. 😎

{Reactions}
😎 😮

[2025-11-29 6:24 a.m.] urish
Started a thread.


[2025-11-29 12:36 p.m.] logic_destroyer
We need more silicon artwork!


[2025-11-29 1:29 p.m.] tholin
On my GFMPW-1 multi-project die, giving an invalid project selection code causes the chip pins to become all outputs and go "RTFM!" in binary ASCII

{Reactions}
😀

[2025-11-29 2:48 p.m.] polyfractal
Hm, so I added a few 256x8 SRAM macros and it seems unhappy about that now. At step 57 (klayout xor magic) I'm getting a slew of errors which seems to stem from:

```
File /home/ubuntu/gf180mcu-project-template/gf180mcu/gf180mcuD/libs.ref/gf180mcu_fd_ip_sram/mag/M3_M24310590878114_256x8m81.mag couldn't be read
Failure to read entire subtree of the cell.

Failed on cell M3_M24310590878114_256x8m81.
I/O error in writing file /home/ubuntu/gf180mcu-project-template/librelane/runs/RUN_2025-11-29_06-44-00/56-magic-streamout/chip_top.magic.gds.
File may be incompletely written. 
```


[2025-11-29 2:51 p.m.] trev5514
Not positive, but it could possibly be related to:

https://discord.com/channels/1361349522684510449/1423348662318272592/1443879406962610287


[2025-11-29 2:52 p.m.] polyfractal
was just scrolling up to that. will give it a shot!


[2025-11-29 3:09 p.m.] polyfractal
while that's chugging along, what's the general road to fixing PVT violations? I guess the easiest fix is just dropping the clock right? any other config changes/tweaks, or is it mostly down to clock speed + layout + what the code is doing?

Edit: related, how much should I care about the non-nominal PVT corners? if nominal looks good are you generally good to go, or is it pretty important to make sure the other corners are passing too?


[2025-11-29 3:21 p.m.] tholin
Another DRC clean build

{Attachments}
2025-11_media/chip_top_black-949ED.png

{Reactions}
🎉 (6) 💯 (3)

[2025-11-29 5:03 p.m.] trev5514
My understanding is that a hold violation will make the chip non functional, setup timing means it just can't operate at the set clock speed at those corners. I'd say it depends on your chips use case. If you expect the chip to never deviate from normal operation (no power supply issues) or in hot/cold temps then yes you can ignore them if you choose. However those corners cover cases when you say get a power supply surge/drop or the chip get's really hot/cold so they are very important if you don't assume ideal.

{Reactions}
👍

[2025-11-29 5:09 p.m.] polyfractal
makes sense! I'll focus on Holds. Probably easiest to just drop the clock rate, doesn't particularly matter anyway for a demo chip.

i just found some docs on OpenLane which look helpful for improving my background knowledge too, and some config values to tweak: https://openlane2.readthedocs.io/en/latest/usage/timing_closure/index.html


[2025-11-29 5:10 p.m.] logic_destroyer
Leo taught me that you should eliminate all hold violations in the different voltage domains, and that this is very important. Setup violations are a different matter — you can always deal with those later by adjusting the clock frequency.


[2025-11-29 5:13 p.m.] polyfractal
noted! is there a shortlist of "ways to fix" that I should be aware of (other than what's at that openlane page)? I'm so new to this I don't really know what knobs are available 🫠


[2025-11-29 5:14 p.m.] logic_destroyer
You won’t believe it, I’m a newbie too.

{Reactions}
😀 😮

[2025-11-29 5:15 p.m.] logic_destroyer
but Leo has helped me a lot.


[2025-11-29 5:15 p.m.] logic_destroyer
And luke


[2025-11-29 5:59 p.m.] tholin
It turns out the C64 SID has two built-in ADCs, which I am trying to replicate in my recreation of it as well. Interestingly, they are implemented using just digital logic cells because they’re not true ADCs and are more like....resistance to digital converters. Each ADC pin requires a capacitor and resistor (usually a potentiometer) connected to it. The chip runs a loop of pulling those pins low for a bit, before tri-state-inputing them and running a timer until they register a logic one.

{Reactions}
❤️

[2025-11-29 6:00 p.m.] tholin
Obviously, this depends on the RC circuit’s time constant.


[2025-11-29 6:00 p.m.] tholin
Fixing the resistor to measure the capacitance also works.


[2025-11-29 6:01 p.m.] tholin
Maybe someone here will find this trick useful.

{Reactions}
👍

[2025-11-29 7:35 p.m.] rzioma
That mechanism is also similar readout mechanism for potentiometers in paddle controllers - in Atari Pokey chip and Atari 2600 TIA chip!


[2025-11-29 7:41 p.m.] mole99
Please check out the LibreLane docs: https://librelane.readthedocs.io/en/latest/
LibreLane is the successor to OpenLane 2, so the docs should be more up to date :)

{Reactions}
❤️

[2025-11-29 7:42 p.m.] mole99
First thing would be to look at the clock tree in OpenROAD GUI to see if it's reasonably balanced.
If that's the case, then increasing the hold slack margin should mostly resolve the hold violations.
If there are still some remaining, taking a closer look at the timing paths can be helpful.

{Reactions}
❤️ (2)

[2025-11-29 8:39 p.m.] polyfractal
these docs are great, giving them a thorough read-through now. Project template request as complete newbie: I see the docs are linked for nix install, but I _totally_ missed that it also included more general documentation about the build process. 😅  maybe a subsection heading that's basically "If you have questions about build output read these docs" ?

followup questions: how do i judge if the clock tree is balanced? Just visually, seeing if it branches somewhat-nicely?

ditto to how should I check timing paths?


[2025-11-29 8:41 p.m.] polyfractal
here's where I'm at currently. Pretty substantially bad on the ss cases but I think trending towards ok everywhere else?

{Attachments}
2025-11_media/Screenshot_From_2025-11-29_12-20-42-C101E.png


[2025-11-29 9:00 p.m.] polyfractal
(hmm I do see that the clock line initially has to wind all the way from bottom left up through a bunch of sram blocks. Can probably re-configure everything so the logic is down in the clock corner)

{Attachments}
2025-11_media/image-D6548.png

{Reactions}
🎉 (2)

[2025-11-29 9:13 p.m.] trev5514
I meant to ask this a while ago but forgot is anyone using cocotb tb with SRAM and passing? I'm using verilator and I get quite a few complaints.

```
gf180mcu_fd_ip_sram__sram512x8m8wm1.v:132:28: Unsupported: minimum/typical/maximum delay expressions. Using the typical delay
  132 |   specparam Tcyc = 55600 : 55600 : 55600;
      |       
```

This is a typical error. I got this weeks ago and replaced the entire sram section with those with a:

```verilog
`ifndef VERILATOR
  specparam Tcyc = 55600 : 55600 : 55600;
...
`endif
``` 

Then outside the specify block I did:

```verilog
`ifdef VERILATOR
  parameter Tcyc = 8183;
  parameter Tckh = 4000;
  parameter Tckl = 4000;
...
`endif
```

Is there a better way? Since now it's failing all github deployments automatically since it's using the repo direct and not my local changes.


[2025-11-29 9:28 p.m.] asc9742
Is LVS of the foundry io pads able to pass using the netgen LVS script from the project template?
The netgen script we have is causing issues with the pads (see questions channel "Running LVS for padframe")


[2025-11-29 9:40 p.m.] tholin
I know you can pass parameters to verilog modules during instantiation, but is it possible to then use those parameters inside the module to do conditional compilation?


[2025-11-29 9:40 p.m.] tholin
I need to `ifdef exclude some stuff in a module, but only during one specific instantiation of it.


[2025-11-29 10:03 p.m.] bailey8889
Try `gds flatglob`ing these cells before reading the gds in magic
```
*Bondpad*
*CLAMP_COR*
*FILL*
*METAL_RAIL*
*NMOS_*
*POWER_RAIL_COR*
*_BASE*
*comp018green*  
*diode_nd2ps_06v0_*[A-Z]*
*diode_pd2nw_06v0_*[A-Z]*
*mim_*_*[A-Z]*  
*moscap_*
*nmos_*_*[A-Z]* 
*nmos_4T_metal_stack*
*nmos_clamp_*   
*pmos_6p0_esd_* 
*power_via*     
*ppolyf_u_*[A-Z]*
*top_route*     
```


[2025-11-29 11:07 p.m.] trev5514
Do you mean like this?

https://stackoverflow.com/questions/52061466/verilog-conditional-hardware-based-on-parameter-value

{Embed}
https://stackoverflow.com/questions/52061466/verilog-conditional-hardware-based-on-parameter-value
Verilog conditional hardware based on parameter value
Is it possible to create conditional hardware in Verilog depending on the value of a parameter? Something like this

module test #(
 parameter param = 1
)(
  input wire clk
);

reg[3:0] counter = 0;
2025-11_media/apple-touch-icon%402-3834B.png


[2025-11-30 12:28 a.m.] logic_destroyer
Dear @LukeW , @Leo Moser (mole99) 

The previous code corrupted the entire netlist for the control signals. I checked your riscvboy-180 implementation and saw that your anchor tricky style approach works for synthesis.  Can I  simply declare rst_pad as a false path in sdc?

{Attachments}
2025-11_media/image-5D7D1.png


[2025-11-30 12:31 a.m.] logic_destroyer


{Attachments}
2025-11_media/message-723E6.txt


[2025-11-30 12:53 a.m.] rebelmike
Would an `if` inside a `generate` block do what you need?


[2025-11-30 12:54 a.m.] tholin
Yes


[2025-11-30 1:50 a.m.] logic_destroyer
During gate-level simulation I found that **CEN has to remain high for one clock cycle**. I had previously hardwired it to 0, but I’ve now combined it with `reset_n`, so the SRAM is operational.

{Attachments}
2025-11_media/image-1AA63.png


[2025-11-30 1:50 a.m.] logic_destroyer


{Attachments}
2025-11_media/image-638B3.png


[2025-11-30 1:51 a.m.] _luke_w_
I am fairly certain the `cen_fell` thing is a bug in the RAM model where they don't initialise all of their variables


[2025-11-30 1:51 a.m.] logic_destroyer


{Attachments}
2025-11_media/image-A2BF5.png


[2025-11-30 1:52 a.m.] _luke_w_
ah maybe I had a separate issue which is the model doesn't accept the first access if you start up with CSn high


[2025-11-30 1:53 a.m.] _luke_w_
I haven't looked at the schematic for the SRAM but that would be a super weird requirement 🤔

{Reactions}
😮

[2025-11-30 1:53 a.m.] logic_destroyer
My caches are working!

{Reactions}
👍 (2)

[2025-11-30 1:53 a.m.] _luke_w_
yes IMO it's ok to falsepath the reset pad input since it's synchronised before use

{Reactions}
❤️

[2025-11-30 1:54 a.m.] logic_destroyer
I was able to boot from flash, copy the code into SDRAM, and execute it via micron sdram model.


[2025-11-30 1:54 a.m.] _luke_w_
nice

{Reactions}
❤️

[2025-11-30 1:55 a.m.] logic_destroyer


{Attachments}
2025-11_media/image-B7C8B.png


[2025-11-30 1:55 a.m.] _luke_w_
@Leo Moser (mole99) those 0.5 x 0.5 slots are so cute 🥺  think they would be a great gate-golf target

{Reactions}
❤️

[2025-11-30 1:55 a.m.] logic_destroyer
I got the model from you Luke 2022 🙂

{Reactions}
👍

[2025-11-30 1:56 a.m.] _luke_w_
how did we choose the number of VDD/VSS pins? seems to  have like 75% the IOs of the 1x1 but < 50% the power and ground pins

{Reactions}
😮

[2025-11-30 2:02 a.m.] trev5514
FYI for my application, SRAM should remain on once started, I added a small prime latch where on reset, it toggles the CEN for a cycle to ensure it's always started.


[2025-11-30 2:03 a.m.] logic_destroyer
that was my fix!

{Attachments}
2025-11_media/image-F0EB1.png

{Reactions}
👍

[2025-11-30 2:32 a.m.] logic_destroyer
Does anyone have a simple SD card Verilog model for iverilog? I only need SPI support, then I could try booting xv6 Unix.

{Attachments}
2025-11_media/image-A6D2A.png


[2025-11-30 7:34 a.m.] greg.hashtag.9468
Looks like it's coming together. This is an updated serv soc design.
28 cores, with each processor making use of the SRAM block for registerfile/program text and ram.
A small FSM pre-loads each cores memory from SPI flash. (similar to an FPGAs bitstream)
The cores are connected via a cross-bar to peripherals. One of which enables core to core communication, via queues or flags.

{Attachments}
2025-11_media/chip_top_black-B7C64.png

{Reactions}
🎉 (4) 😮 (2)

[2025-11-30 7:38 a.m.] greg.hashtag.9468
Given the logic density, I think I could fit 32 cores in there... But didn't want to hit a wall with routing.


[2025-11-30 7:40 a.m.] greg.hashtag.9468
A cross-bar between every core isn't a very scalable solution. But gives a lot of flexibility to the application


[2025-11-30 8:44 a.m.] logic_destroyer
CoreScore style @Greg ?


[2025-11-30 8:45 a.m.] logic_destroyer


{Attachments}
2025-11_media/Screenshot_20251130_094540_Chrome-51801.jpg


[2025-11-30 8:46 a.m.] greg.hashtag.9468
I did take a look at corescore. We can probably make this the highest ranking serv ASIC on that list 😉

{Reactions}
😀 (3)

[2025-11-30 8:58 a.m.] logic_destroyer
@Leo Moser (mole99)


[2025-11-30 11:03 a.m.] mole99
Thanks Hirosh, I did see the question, I just haven't had time to reply yet :)

{Reactions}
❤️

[2025-11-30 11:04 a.m.] mole99
The default pinout of the 1x1 slot is based on the TT chip: https://docs.google.com/spreadsheets/d/1sZCpz6yy-bHGaV2BVG4IZOLBWn--WIddM9pkCQm_Vyc/edit?gid=0#gid=0
A number of the VDD/VSS pads will be used for the analog power domain in the future.

In addition, the core are of the 0p5x0p5 chip is less than a quarter of that of the 1x1 chip. That's why I reduced the number of power/ground pads considerably.
It may turn out that this is not enough to support the number of I/Os at high speeds, so we might change that again for run 2.

{Reactions}
❤️

[2025-11-30 1:07 p.m.] rzioma
Z80 in a **quarter** slot. I think it is cute!

{Attachments}
2025-11_media/image-87C55.png

{Reactions}
👍 (3) ❤️ (3) 🇿 (2) 8️⃣ (2) 0️⃣ (2) 🥺

[2025-11-30 1:10 p.m.] rzioma
@Leo Moser (mole99) quarter slot works! 🙂


[2025-11-30 1:31 p.m.] rebelmike
I noticed the project template SDC file has `set_input_delay -min 0 -clock $clocks $clk_core_input_ports` which sets the hold time on the inputs to zero.  I think that's may be why you've had to turn up the hold slack margin, because it means a bunch of buffering is required on the inputs which is a bit difficult for the flow to get right.

{Reactions}
😮

[2025-11-30 2:04 p.m.] mole99
Make sure to also check that the actual timing of the clock tree in the "Clock Tree Viewer".

This shows the example template where the design is quite sparse so there's a lot of routing between the clock buffers and after SPEF extraction the tree isn't as balanced as it should be (that's why I had to increase the hold margin).

{Attachments}
2025-11_media/Bildschirmfoto_vom_2025-11-30_14-50-47-CC69A.png

{Reactions}
👍 ❤️

[2025-11-30 2:07 p.m.] mole99
For a detailed report on the timing paths, take a look at `librelane/runs/<timestamp>/54-openroad-stapostpnr/<corner>/` and open `min.rpt`/`max.rpt` for hold/setup checks.


[2025-11-30 2:11 p.m.] logic_destroyer
Have you implemented PIO and SIO?


[2025-11-30 2:17 p.m.] rzioma
Well, I looked at a bunch of Z80 computers from back in the day… and I couldn’t find almost a single one that would use Zilog’s PIO/SIO.

So I am actually thinking to focus on ZX Spectrum like machine repairs and put ULA (graphics) and AY (audio) instead.

{Reactions}
😮

[2025-11-30 2:18 p.m.] rzioma
If I am missing some, let me know plz!


[2025-11-30 2:18 p.m.] logic_destroyer
I have no idea 🙂


[2025-11-30 2:19 p.m.] rzioma
Plus 16KB of RAM if I go full slot.

{Reactions}
😮

[2025-11-30 2:46 p.m.] polyfractal
aha, didn't know that little widget existed in the gui, cheers! Didn't see the timing report tab either. looking through the violators now, looks like my ALU is popping up in the list which is interesting. didn't think I had anything particularly expensive in there but will give examine it closer.

thanks for all th ehelp!

{Reactions}
👏 (2)

[2025-11-30 3:38 p.m.] tholin
Just one more design. I can still fit more. I can do just one more design!

{Attachments}
2025-11_media/chip_top_black-D1C61.png

{Reactions}
❤️ (4) 👏

[2025-11-30 5:17 p.m.] tholin
I think I’m a little behind. I still have not submitted any GDSIIs and let precheck run.


[2025-11-30 5:17 p.m.] tholin
How do I even do this?


[2025-11-30 5:34 p.m.] trev5514
You can do it locally:
https://github.com/wafer-space/gf180mcu-precheck

But I believe the test project is where we will end up submitting which just runs that on a server:
https://doc.test-platform.wafer.space

I'd do it locally, mine timed out on the website.

{Embed}
https://github.com/wafer-space/gf180mcu-precheck
GitHub - wafer-space/gf180mcu-precheck: Precheck for wafer.space MP...
Precheck for wafer.space MPW runs using the gf180mcu PDK  - GitHub - wafer-space/gf180mcu-precheck: Precheck for wafer.space MPW runs using the gf180mcu PDK

{Embed}
https://doc.test-platform.wafer.space/
Welcome to wafer.space
…
Platform for wafer.space low cost silicon manufacturing.


[2025-11-30 10:22 p.m.] logic_destroyer
It would be nice to run the SPICE model. I could run it on a remote server and check what it does after a year. How can I run something like that in SPICE?


[2025-11-30 11:12 p.m.] tholin
I tried to use the online platform, but it just keeps cycling between "Queued" and "Starting"


==============================================================
Exported 654 message(s)
==============================================================